Recently, Charles King of Pund-IT Review was kind enough to send me a link to an old blog post talking about a type of bad software development experience that the writer had undergone – one that the writer christened “A*h*-Driven Development”, or ADD. The comments on that blog post added some other wonderful designations of bad development experiences, complete with acronyms, many of which I enjoyed as well – until it struck me that in my 12-year developer career I had not experienced any of them.
And so, Charles has inspired me to set down my own experiences of misbegotten, crippled-from-the-start development, with due attention to appropriate acronyms. And if you don’t like it, remember, don’t blame me for this post – blame Charles.
Commentless Reverse-Engineered Ugly Development (CRUD)
In my time, I ran into two extraordinary examples of this phenomenon. The first was the case of a talented but strange person who had single-handedly created the first version of the software for an intelligent terminal. This was in the days when in order to develop software for certain firms, one had to write out the programs (in Intel 8080 assembler language, of course) and then submit them to typists who would type in the written program, then run the compiler and linker and passed back the results to the programmer, until the program worked.
However, the person who created the first version did not believe in comments, so it was very difficult to determine how the program worked. What’s more, that person had a tendency to label statements that were to be branched to with obscenities, so that the typists had reached the point of refusing to type in his code. Above all, the person was surly to the point that asking him to do a far larger second version in a timely fashion was risky if not asking the impossible. However, it was also necessary that the second version provide the functions that the first version did, to ensure that customers went for the upgrade.
Eventually, management bit the bullet and hired more developers who would do v2. However, because of the lack of comments, the functions of v2 had to be reverse engineered: these developers had to guess just how the original developer had created these functions in v1. In the end, the development had to take a long while to create a massive initial specification that included “best guesses” as to how v1’s functions worked, and the usual discoveries of problems combined with the new problems of coordinating multiple programmers made the development process very long. Eventually, v2 got done; but by that time, the lead in the market that v1 had given had pretty much dissipated, as I understand it.
And that talented but strange developer? Upper management found a solution that to my mind smacks of genius: they promoted him to be a software development manager. No more obscenities, no more surliness; he had to get what he wanted done through other programmers, and in order to do it he even improved his physical appearance so he wasn’t so unsanitary. In fact, after his transformation he was by no means the worst personality problem among the developers – that would be someone we called the Mad Russian. But that’s a story for another time.
On to story number two. This was in later times, when one had one’s own IBM terminal to type in, compile, and link programs that were written not in assembler but in what used to be called a 4GL – a language a step up from C or PL/I, and vaguely English-like in its commands. This particular company had a “wonder installer” who knew the product inside and out and knew just how to make the latest version run superbly when he installed it at customer sites. In effect, he was so good that he seemed to sell the customer himself.
And then the next version of the product would come out, and if he did not install it, screams of anguish would arrive from existing customers about all sorts of vital programs that didn’t work – this despite careful efforts at backward-compatibility testing by some extremely capable programmers. What on earth could be going on?
As it turned out, when this installer would show up at a customer site, the customer would in the course of installation say, “gee, wouldn’t it be nice if …” and the installer would say “Of course I can do that for you”, and in a flash would whip up a program based on the product that would do just what the customer wanted. There was one problem: that little add-on was based on the innards of version x, and when version x + 1 arrived, those innards had changed, and the add-on no longer worked. Of course, testing did not catch the problem, because users were only supposed to use the interfaces, not the innards beneath them. And, of course (since a 4GL was English-like, the installer assumed no commenting was needed), there were no comments explaining what the program was doing, and the installer was out doing another job, and there was a key customer screaming bloody murder.
In the end, as in case 1, some of these programs had to be “reverse engineered”. Luckily, the programs were generally small, so it was less difficult to accomplish this. Still, it continually slowed down development of new functionality in the product, because these programs that only one or two key customers wanted were preempting new functionality that most customers needed.
I don’t know for sure how the company finally solved this problem. I think that they finally pulled back the installer from the field and redirected him to new-function design, where it was impossible for any of his little per-company customizations to make it into running product. In the end, as in story 1, a good but clueless programmer created CRUD, and the company that had to clean up the mess decided it never wanted CRUD again.
Design-By-Meeting Endless Asinine Development (DEAD)
I don’t know what your reaction to this story will be, gentle blog reader (OK, just a little snark), but even 30 years later I cannot believe it actually took place. Here goes.
Again, this involves a software company using a 4GL (yes, the same company), and this time I should note that one of its products was a database. At the time of which I write, the company decided that the accompanying data dictionary needed a major refresh, and the person who had been upgrading the product all along moved on to other things, while a mostly-new development team was brought in to create that plus a new development tool for the 4GL – and one more person, crossing over from sales and assuming the position of overall development manager. I believe that she apparently had no development or development management experience, but some first-line sales managerial experience.
At this point, I think I should make one thing clear. As I sometimes put it, “The worst development manager I had was a woman; and the best development manager I ever had was a woman.” Someday I hope to write about why I feel that Leslie Turek, then of Computer Corp. of America, was and is my beau ideal of a development manager, even better than several superb managers I had during my development career. Even though, to me, the manager mentioned in this story is the worst development manager I had, I don’t believe that most of the problems were her fault. She was, simply, wrongly put by the company into a situation in which because of her lack of previous experience it was practically impossible for her to avoid managing development poorly.
Anyway, so here you are, tasked with managing multiple developers, with no experience or software programming knowledge as a guide, and with your first task being to create a design spec for the new product in seven weeks. What do you do? Well, this manager’s idea was to sit the programmers down in a meeting and have them discuss it, then reflect that discussion in an agreed-on design spec. As part of the team, although I was in parallel creating a design spec for the development tool, I was expected to attend and contribute.
Sounds plausible, yes? Except that what it turned out to mean was seven consecutive weeks of meetings from 9 to 4:30, Monday through Friday, with ½ hour break for lunch. And don’t forget that this was our manager running the meetings. Any sign of deviation from the consensus as she saw it was delaying the completion of the spec and a black mark against you. Any undue sign of impatience or inattention due to the exhausting nature of sitting there concentrating on very fuzzy stuff for hours was a black mark against you. And those who, like me, sometimes had limits on how much into the night we could work in order to write down the day’s production into an evolving design spec (in my case, because I had to get home to help with an autistic son) got black marks.
Here’s an example of how the process worked – or rather, failed to work. At the point where we had to decide on the data dictionary’s user interface, the manager happened across someone who had begun to do academic-style research on user interfaces, and had discovered that in menus, if there were more than seven choices, users would forget about some of the choices. This immediately got translated in the manager’s mind into “we should use menus” as well as “menus should have no more than seven choices.” We then spent two hours generating off the top of our heads menu choices for a particular screen that “we really should have.” There was no consideration of whether the choices could be implemented given the information that the data dictionary would have; there was no discussion of how readable the menu choices we generated were; as often happens in this sort of idea generation, we wound up with 10 menu choices instead of 7; and there was not even any consideration of making the choices involve action verbs or otherwise making the differences between the choices apparent to the reader. No; what mattered was that there was a great deal of detail provided by all of these menu choices, and by sheer weight of detail this would look great in a design spec to the untutored eye.
I spent much of that two hours (and the rest of the meetings) screaming in silent designer agony. I had at the same time created in my mind and noted simply on paper a design for the development tool that had a user interface with typically three choices per screen, very simply and clearly put – what I have called in other posts “orthogonal.” I had little time to flesh out my own design spec because of these meetings. And raising a point about anything I have listed above would require objecting at the end of the discussion – because only then would it become clear that there would be no discussion of these points. And if I did that, then I would get a black mark for going against the consensus as the manager viewed it and delaying the spec creation process uselessly.
The rest of the story, really, is anticlimax. At the end of the seven weeks, the manager decided that because of the lack of detail in my design spec, I should be cut loose. I stayed on to help another programmer to complete the development tool that I had designed, a process that we completed in 2 ½ months despite the lack of “detail.” I was told later that the development tool was widely implemented and well received by the customer base. Meanwhile, as I was also told later, the data dictionary kept missing deadlines. Finally, after about nine months of development, the programmers under my manager revolted and literally refused to work for her any longer. I am not sure whether some form of the data dictionary that this design by meeting specified was ever implemented, but it was certainly not the full design.
The moral of the story, to me, is simple. If one tries to design by meeting, and by nothing but that, in the long run (say, a year from now), the careers of all involved in the company are DEAD.
What really strikes me, looking back all these years later on these (to me) horrible development-process experiences, was how few of them there actually were. Perhaps I’m an old softie, inclined to sugar-coat my younger life – naah. Or perhaps those who contributed comments to the blog post Charles sent me really are experiencing a greater frequency of lousy development experiences. Somehow I doubt that, as well. In my early years, especially, managers were just beginning to realize that there was more to software-development management than there was to managing, say, the accounting arm. I know there were a lot of clueless and therefore paranoid managers out there; I think I was just lucky enough to run into fewer such experiences.
But it still puzzles me that no one out there has mentioned the kind of experiences I had. Maybe that is a hopeful sign. Maybe, in the words of the Latin teacher in Rudyard Kipling’s Stalky & Co., “you see, even among the barbarians – some of it sticks”. “Amen,” said the chaplain. “Go to bed.”