J. SYSTEMS SOFTWARE 1 1990; 11: l-2

Editor’s Corner* Robert L. Glass

Software Design: Is There Madness in a Method?

When you think about software design, what do you think about? How about the methodology you’re go- ing to use to produce the design, and the language you’re going to represent the design in? That’s what most people think about these days. That’s what I call the methodology f representation school of software de- sign. Well, I think there’s a problem with that school. For one thing, it ignores the fact that design is something that goes on inside the mind of the designer. Methodol- ogy can steer the process of design, and representation can be used to write it down, but in actual fact design is a creative and lonely effort, a test of the mind of the designer, and no amount of mc~odology and represen- tation can make up for a lack of mental agility on the part of the designer.

Now this is not an original thought. A man named Christopher Alexander, back in 1964, wrote a book called Notes on the Syn~~esj~ of Form. It was about architectural design, and in it Alexander did two impor- tant things- he described a design process where the totality of design was made up of an integrated (Alexan- der called it “fused”) set of independent diagrams, or patterns, and he described a method which led to the creation of these diagrams.

Alexander’s ideas caught on, and before long a whole academic field had grown up around the methods for creating the diagrams. Meanwhile, Alexander had a chance to think about what he had done.

In 1971, seven years later, Alexander brought out a new edition of the book. This time, he put a new focus on his previous findings. The diagrams were the impor- tant thing, Alexander said. And then he said something even more important. “I reject the whole idea of design methods as a subject of study,” he said, “since I think it is absurd to separate the study of designing fro-m the practice of design. ”

“In fact,” Alexander went on, gathering momentum, “people who study design methods without also practic-

* This aditorid was reprinted with permission fmm the column “Software Refractions” by Robert L. Ckss, in Systems Revelop- ment, P.O. Box 9280, Phoenix, AZ 85068.

@ 1990 Elsevier Science Publishing Co., Inc. 655 Avenue of the Americas, New York. NY 10010

ing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never have anything sensible to say about ‘how’ to shape things either. ”

That’s pretty much of a “wow.” It is obvious that Alexander felt pretty strongly about what he had learned, and what people had chosen to do with what he had learned.

But this is an editorial about software and software design. How much of what Alexander said has anything to do with software?

I think a lot. I think we’ve been playing the same games that Alexander’s followers played. I think we have found that creative design, that mysterious process that goes on inside the mind, is so hard to define that we’ve taken a cop-out. And that cop-out is that we’ve begun to teach design me~odology as if we were teach- ing design. I’ve lost count of the number of structured approaches to design that one could learn, or the variety of symbols and shapes one must learn to learn those ap- proaches. Those approaches are nice to teach, because they have a feel of hard science to them. There are lots of “facts” to be taught and learned. “If you draw this diagram in this way, then your design is good; if you do not, then your design is bad.”

Somehow, I think, all of that trivializes design, It’s just not that simple. That’s what a fellow named Dave Brown found, back in July of 1984, when he wrote an article for ACM Software Engineering Notes called “Why We Did So Badly in the Design Phase.” He and his design team got so caught up in the methodology + representation school of design that there really wasn’t time to do enough of that truly creative thing- design it- self. “An excess of design documentation literally drove out design proper,” he said; “We never had the time to notice that there was a simple, elegant answer to the problem. ”

OK, then, the design representation stuff got in the way of the real design. But what, really, is design?

Answers to that long-elusive question are finally com- ing. People who study what designers do, people who

OH-1212/90/$3..50

2 J. SYSTEMS SOFTWARE

1990; 11: 1-2

conduct protocol studies using actual designers doing actual designs as subjects, have begun to come up with some empirical findings. And the findings look pretty realistic. Designers do these things:

1.

2.

3.

4.

5.

They come to an understanding of the problem to be solved. They create a simplistic model in their mind which they hope will solve the problem. They run a simulation using the model, supplying it with sample inputs, and executing it in their minds to see if it produces the desired sample outputs. They identify the flaws in the candidate model, and enhance it to cover those flaws. They repeat steps 2-4 until the model is sufficiently enhanced to properly handle the problem as it is un- derstood.

Now those five steps look pretty methodical here on paper. But in fact they are conducted at lightning speed within the mind.

The mind is essentially undertaking a complex, it- erative, problem-solving exercise, involving modeling

Editor’s Comer

and simulation, and during that exercise both methodol- ogy and representation are ignored, because they would only get in the way. It is only after that modeling- simulation process begins to reach closure that what we have thought was design, the methodology stuff and the representation stuff, really comes into play.

Where is this empirical research being done? Some of it began at Carnegie-Mellon University several years ago. But the chief explorers now are people who work with Bill Curtis at the Microelectronics and Comput- ing Consortium (MCC), and with Elliot Soloway at the University of Michigan (formerly at Yale). There, they interview and monitor and audiotape and videotape live design sessions, trying to be as unobtrusive as possible, to see what makes the design process really tick.

These findings will be worth watching. They are so new we’re not exactly sure what to do with them. Do we teach them? Or is that falling into the same trap that Alexander identified, teaching about how to do design in the absence of actually doing it?

There’s a lot more to be learned here. Stay tuned for further developments.