J. SYSTEMS SOFTWARE 101 1994; 26:101-102

Editor’s Corner The Faking of Software Design

Robert L. Glass

It’s not often that someone is brilliant enough to solve a problem before the rest of us can even see that there is one. But this is a story about just such an event.

Once upon a time, more than a decade ago, all of us in software learned that top-down, requirements- driven approaches were the best way to build soft- ware. We take the top-level requirements and use hierarchic decomposition techniques to chop a big, unsolvable problem up into a bunch of smaller solv- able ones. When we are done, there is this nice tree-structure -like definition of our problem and our solution. Then something strange happened. One of the best-known of the computer scientists, David Parnas (who gained perhaps his greatest fame via his paper on the decomposition of software into mod- ules), wrote an odd paper that essentially told us how to fake top-down design when we write our design documentation; the words “fake it” were even in the title of the paper!

Fake top-down design? Why should we do that? Time passed. Parnas’s paper seemed an anomaly,

something out of synch with the rest of the brilliant work he had done. Fake top-down design indeed! And then, from another part of the computing forest came another rather strange finding. Bill Curtis, leading a group of computing researchers at the Microelectronics and Computing Consortium, began to do empirical studies of the process of design as conducted by skilled designers. In Curtis’ early pa- pers, he contrasted two design approaches-con- trolled design and opportunistic design. Controlled design proceeded the way we all knew it should: top down and at least somewhat hierarchically. Oppor- tunistic design proceeded in ways totally dependent on the individual designer, sometimes apparently almost randomly. At this early stage in these find- ings, we all wondered at those disorganized, oppor-

This editorial was reprinted with permission from the column “Software Reflections” by Robert L. Glass in Managing System Der&opmettt, P. 0. Box 82266. Phoenir, AZ 85068.

63 Elsevier Science Inc. 655 Avenue of the Americas, New York, NY 10010

tunistic designers. Why would they behave in such an obviously incorrect way?

But as more time went by, the findings of the Curtis people changed. Controlled design, they be- gan to see more and more often, was not what good designers really did. Opportunistic design became more and more what they observed in their studies. The designer’s mind, engaged in solving one prob- lem, would dart off to another, usually more com- plex, problem. If one thought of the overall and emerging design as the tree structure we all thought it should be, then these opportunistic diversions went to places on the tree remote and relatively unconnected to the place where the mind was nomi- nally functioning.

What was going on here? Whatever it was, the finding became so prevalent that Curtis began say- ing, publically, things like “The undisturbed design process is opportunistic.” People simply don’t do what we were all sure they would be doing. Were we observing a fundamental flaw in how practitioners design software? Or were we observing a fundamen- tal flaw in our model of how they should design software?

It is time now to reintroduce Parnas’ “fake it” methodology into our story. Remember that, for some odd reason, he told us how to fake a top-down design in our documentation even if we hadn’t done our design in that way?

In Curtis’ findings lies the explanation. Those opportunistic designs produced by good designers simply are not top down. And yet it would be impos- sible for nondesigners to follow the opportunistic trail of the creative process of building such a de- sign. So we “fake” a top-down description of the design because that is the only way readers of the design will be capable of understanding it.

And with the Parnas piece of the puzzle clicking into place with the Curtis pieces, we begin to see that the problem lies not with design practice, but with design theory. Theory was idealized and, as it turned out, inaccurate. Our fundamental flaw lay in the model of the design process, not in its practice,

102 .J. SYSTEMS SOFTWARE 1994; 26:101-102

Editor’s Corner

So where does this leave us? With our theoretical model of design, which serves us well as a represen- tation schema, even if we have to fake it, and with our empirical model of design, called “opportunistic” by Curtis, which serves us well as the real way we perform our design activities.

Because the term, opportunistic still has a strange, perhaps random, perhaps even negative connotation, I like to think of this process in another way. When the mind reaches off in its opportunistic way, most often what it is doing is making sure that it solves the hard problems before it solves the dependent easier ones. We could almost define a new kind of tree-structure here, one driven not from the top by its overall requirements, but by some ordering of difficulty blended with coupling.

But there is a problem with that view. What is a hard problem to one person may not be to another;

problems tend to be hard if we have not solved them before, and each of us brings a different set of experiences to the act of design. Therefore, each person’s hard problem tree structure will be differ- ent from each other person’s. How can a sensible model of design be built from that?

I prefer to think that the act of design is and should be what I call hard-part-first design. I believe that covers, at least to some extent, what Curtis’ empirical studies have discovered. And hard-part-first has a more organized image (whether it should or not!) than opportunistic.

Be that as it may, it is not the terminology that counts here, so much as the understanding. Design is and ought to be opportunistic. Design representa- tion ought to be, and usually is, top down. And David Parnas gave us the answer even before most of us understood the question!