3. What’s Wrong with This Model?
Software’s Waterfall Model
After Royce [1970], “Managing the development of large software systems,” and Boehm [1988], “A spiral model of software development and enhancement.” Royce © 1970 IEEE. Boehm © 1988 IEEE.
Sometimes the problem is to discover what the problem is.
GORDON GLEGG [1969], THE DESIGN OF DESIGN
A designer makes things. ... Typically his making process is complex. There are more variables—kinds of possible moves, norms, and interrelationships of these—than can be represented in a finite model.
DONALD A. SCHÖN [1984],
THE REFLECTIVE PRACTITIONER
In fact, every designer will recognize the Rational Model as only an ideal. It somehow describes how we think the design process ought to work, but not how it works in real life.
Indeed, not every engineer will even admit to harboring so naive and idealistic a model in his heart. But I think most of us really do; I did for quite a long time. Therefore, let us take a hard critical look at the Rational Model of design, to identify precisely where it most departs from reality.
We Don’t Really Know the Goal When We Start
The most serious model shortcoming is that the designer often has a vague, incompletely specified goal, or primary objective. In such cases:
The hardest part of design is deciding what to design.
As a student I spent one summer working at a large missile company, where I was once set to work designing and building a little database system for keeping track of the 10,000 drawings for a radar subsystem, and the updating status of each.
After a couple of weeks, I had a working version. I proudly presented a sample output report to my client.
“That’s fine—it is what I asked for—but could you change it so that . . . ?”
Each morning for the next few weeks, I presented my client with the output report, revised yet again to accommodate the previous day’s request. Each morning he studied the product report and asked for yet another system revision, using the same polite mantra.
It was a simple system (implemented on punched-card machines), and the revisions were conceptually simple. The most comprehensive change was to list the drawings sorted by, and indented to show, goes-into level, where level was represented by a single 0–9 digit in the card. Other refinements included multilevel subtotals, with exceptions of course, and the automatic marking of various noteworthy values with asterisks.
For a while, this frustrated me sorely: “Why can’t he make up his mind as to what he wants? Why can’t he tell me all at once, instead of one bit a day?”
Then, slowly, I came to realize that the most useful service I was performing for my client was helping him decide what he really wanted.
Well, today the software engineering discipline is much more sophisticated. We recognize that rapid prototyping is an essential tool for formulating precise requirements. Not only is the design process iterative; the design-goal-setting process is itself iterative.
This sophistication in software engineering does not forestall, or noticeably reduce, the numerous references in the literature to the “product requirements” as a normal given for a design process. But I will argue that knowing complete product requirements up front is a quite rare exception, not the norm:
A chief service of a designer is helping clients discover what they want designed.
In software engineering, at least, the concept of rapid prototyping has a name and a recognized value, whereas it does not always have the same status in computer design and in building architecture. Nevertheless, I see the same goal iteration happening in these design fields. Increasingly, designers build simulators for computers and virtual-environment walk-throughs for buildings as rapid prototypes to drive goal convergence. Goal iteration must be considered an inherent part of the design process.
We Usually Don’t Know the Decision Tree—We Discover It as We Go
For the original design of complex structures, such as computers, operating systems, spacecraft, and buildings, each major design effort has enough novelty in the
• Goal
• Desiderata, and the utility function
• Constraints
• Available fabrication technologies
that the designer can rarely sit down and a priori map out the decision tree.
Moreover, in high-technology design, few designers can know enough to draw the basic decision tree for their domains. Design projects often last two years or more. And designers get promoted out of design. Consequently, few designers will work in any depth on as many as 100 projects over a working life. This means the individual designer has not begun to explore all the branches of the basic decision tree for his discipline. For it is characteristic of engineering designers, as opposed to scientists, that they rarely explore alternatives that are not clearly on the way to a solution.1
Instead, designers discover the decision tree as they work—making a decision, and then seeing the alternatives it opens and forecloses for the next consequent design decision.
The Nodes Are Really Not Design Decisions, but Tentative Complete Designs
In fact, the very decision tree is itself only a simplistic model of the tree-search process. As Figure 2-1 illustrates, there are parallel attribute branches, as well as alternative branches. The choices in one branch are linked to those in others—by exclusion, affinity, or trade-off. Our massive design tree in Computer Architecture is much too simple; the entire “Computer Zoo” in that work is necessary to elucidate the decision linkings.2
This means that at each node of a design tree, one faces not a simple alternative choice among options for one design decision, but an alternative choice among multiple tentative complete designs.
Moreover, the ordering of decisions laying out a decision tree matters greatly, as Parnas expounds in his classic paper “On the design and development of program families”3
The explosive combinatorics of these complications to the tree model boggle the mind. (This situation is like that of move trees in chess.) This difficulty is explored further in Chapter 16.
The Goodness Function Cannot Be Evaluated Incrementally
The Rational Model assumes that design involves a search of the decision tree, and that at every node, one can evaluate the goodness function of the several downward branches.
In fact, one cannot in general do this without exploring all the downward branches to all their leaves, for many goodness measures (for example, performance, cost) will depend heavily on the subsequent design detailing. So although the goodness evaluation is possible in principle, one encounters here again the combinatorial explosion of alternatives in practice.
So what is a designer to do? Estimate, of course, either formally or informally. One must trim the decision tree as one goes down.
Experience
Many aids help intuition in this process. One is experience, both direct and surrogate: “The designers of OS/360 exposed detailed formats of system-wide-shared Control Blocks in Operating System/360, and it proved a maintenance nightmare. We will encapsulate them as objects.” “The Burroughs B5000 family long ago explored the descriptor-based computer architecture. The performance hit was inherently too great, so we won’t explore that subtree.” Of course, the technological trade-offs are no longer the same, but the experience lesson is illuminating anyway. The most potent reason to study design history is to learn what doesn’t work, and why.
Simple Estimators
Designers routinely use simple estimators early in the decision tree exploration. A building architect, given a budget goal, applies a rough square-foot cost estimate, derives a square-foot goal, and uses that for subsequent pruning of the design tree. Computer architects use instruction mixes to do rough-cut early estimates of computer performance.
A danger, of course, is that the rough estimator may lop off decision branches that are in fact feasible but appear infeasible because of the very approximation involved in the estimator. I have watched an architect quote high costs for pushing out a wall under an already specified roof structure, based purely on a routine square-foot estimator. In fact, most of the cost of the added space was in the roof, and that was already committed, so the marginal cost was very low.
One can often get something for nothing, if one has previously bought nothing for something.
The Desiderata and Their Weightings Keep Changing
Donald Schön, the late MIT professor of urban studies and education, and a design theorist, said:
[As the designer] shapes the situation in accordance with his initial presentation of it, the situation “talks back” and he responds to the situation’s back-talk.
In a good process of design, this conversation with the situation is reflexive. In answer to the situation’s back-talk, the designer reflects-in-action on the construction of the problem, the strategies of action, or the model of the phenomena, which have been implicit in his moves.4
In short, as one ponders the trade-offs, there comes a new understanding of the whole design problem as an intricately interlocked interplay of factors. With it comes a change in the weightings of the desiderata. The same thing happens as the client, if there is one, grows his understanding of what he will get and develops his detailed vision of how he will use it.
In our house-remodeling design, for example (Chapter 22), a simple question, overlooked in the original program, arose well along in design, as my wife and I applied use scenarios to preliminary designs: “Where will guests at meetings put their coats?” This seemingly low-weight desideratum in fact tipped the big scales, and occasioned moving the Master Bedroom from one end of the house to the other.
Moreover, for designs that must be separately fabricated, such as buildings and computers, the designer learns from the builders a growing understanding of the interactions between design and fabrication. So many desiderata and constraints shift and refine. The fabrication technology may evolve as well, an especially common occurrence during computer design.
Since many desiderata (such as speed) are weighted on a value/cost ratio, yet another phenomenon occurs. As design proceeds, one finds opportunities to add some particular goodness at a very low marginal cost. So something that had not entered the original desiderata list at all comes in, and it often takes on a value that may demand preserving in later design changes.
Only after UNC’s Sitterson Hall was designed, built, and in use, for example, did the Computer Science Department, as user, learn that the suite of spaces consisting of the Lower Lobby, Upper Lobby, Faculty Conference Room, Lecture Halls, and Vestibules combined beautifully into a facility well suited for hosting conferences of up to 125 people, with minimal impact on the work in the rest of the building. This was serendipitous—no such function was contemplated in the original architectural program. Yet it is a high-value feature: any future revision of Sitterson would surely aim to preserve this capability.
The Constraints Keep Changing
Even if the goal were fixed and known, all the desiderata enumerated, the decision tree known precisely, and the goodness function precisely defined, design would still be iterative, because the constraints keep changing.
Often the environment changes—the city council passes new shadow-casting setback requirements; the electrical code has an annual updating; a microchip one planned to use is withdrawn by the vendor. The world keeps changing around us, even while we design.
The constraints also change due to discovery during the design process, or during the fabrication—the builders hit solid rock; analysis shows that chip cooling has newly become a constraint.
Not all constraint changes are increases. Often constraints go away. When this is fortuitous instead of intentional, the skillful designer recognizes the new opportunity and, with his flexible design, leaps to exploit it.
Alas! Not all designs are flexible. More commonly, when we are deep into a design process, we do not recognize that a constraint has disappeared, nor do we remember which design alternatives it formerly foreclosed.
It is important to list the known constraints explicitly at the start of the design process, as part of what architects call the design program. The design program is a document, prepared with the client, that sets forth the goal, the desiderata, the constraints. An example is given in this book’s Web site. The design program is not the same thing as a formal requirements statement, which usually has contractual force in defining acceptability of a design.
The explicit listing of constraints smokes them out early, avoiding unpleasant surprises. It also impresses them on the designer’s mind, radically improving the chances that he will recognize when one goes away.
All of us have designed around constraints, a process that calls forth much invention and exploration of unconventional corners of the design space. This is part of the fun of design, and a big part of the challenge.
Changing Constraints Outside the Design Space
Sometimes, however, a design breakthrough is achieved by stepping completely outside the design space, and working there to remove the design constraint. In designing the house wing (Chapter 22), I wrestled a long time, unsuccessfully, with a shadow-casting setback requirement constraint and the Music Room’s desiderata (hold two grand pianos, an organ, and a square space for a string octet plus a 1-foot teaching margin). Figure 3-1 shows one iteration of the design, and the constraints.
Figure 3-1 Design up against constraints
The intractable design problem was finally solved completely outside the design space—I bought a 5-foot strip of land from my neighbor. This was probably cheaper and surely faster than attempting to get a setback variance from the city council, another outside-the-design-space approach. It also liberated other parts of the design, notably the placement of the northwest corner of F Study (Figure 3-2).
The explicit listing of known constraints in the design program helps here, too. The designer can periodically scan the list, asking, “Can this constraint now be removed because the world has changed? Can it be entirely circumvented by working outside the design space?”
Others’ Critiques of the Rational Model
A Natural Model
The Rational Model as presented and criticized above may seem naive. But it is a very natural model for people to conceive. This naturalness is strongly corroborated by the independent creation of the Simon version, the Waterfall Model version, and the Pahl and Beitz version. Yet, from early on, there have been cogent critiques of the Rational Model from the design community.5,6,7
Designers Just Don’t Work That Way
Perhaps the most devastating critique of the Rational Model, although perhaps the hardest to prove, is that most experienced designers just don’t work that way. While the published critiques have only rarely made the “emperor has no clothes” statement that the model simply does not reflect professional practice, one senses that overriding conviction behind all the detailed analyses.8
Nigel Cross, in his gentlemanly way, is perhaps the most articulate exception. Citing many studies, he says bluntly:
Conventional wisdom about problem-solving seems often to be contradicted by the behavior of expert designers. But designing has many differences from conventional problem-solving. ... we must be very wary about importing models of design behavior from other fields. Empirical studies of design activity have frequently found “intuitive” features of design ability to be the most effective and relevant to the intrinsic nature of design. Some aspects of design theory, however, have tried to develop counter-intuitive models and prescriptions for design behavior [emphasis added].9
And,
The appositional nature of design reasoning has been neglected in most models of the design process. Consensus models of the design process, such as that promulgated by the Verein Deutscher Ingenieure [VDI, 1987] ... propose that designing should proceed in a sequence of stages. ... In practice, designing seems to proceed by oscillating between sub-solution and sub-problem areas, as well as by decomposing the problem and combining sub-solutions.10
I find both the argument and the empirical evidence quite convincing. This oscillation has indeed characterized all my design experiences. The “where to put the coats?” requirement discovered deep into our house design process is typical.
Royce’s Critique of the Waterfall Model
Royce in his original paper describes the Waterfall Model so that he can point out its deficiencies.11 Basically he argues that even with back-arrows describing counterflow between adjacent boxes in the waterfall, the model doesn’t work. His prescription is, however, simply to augment the model with counterflow arrows that go back two boxes. A Band-Aid, not a cure.
Schön’s Summary of the Critiques
[Simon] has identified a gap between professional knowledge and the demands of real-world practice. ... Simon proposes to fill the gap ... with a science of design, his science can be applied only to well-formed problems already extracted from situations of practice.
If the model of Technical Rationality ... fails to account for practical competence in “divergent” situations, so much the worse for the model. Let us search, instead, for an epistemology of practice implicit in the artistic, intuitive processes which some practitioners do bring to situations of uncertainty, instability, uniqueness, and value conflict.12
But Despite All These Flaws and Critiques, the Rational Model Persists!
Often the original proponent of a theory or technique understands its promise, its liabilities, and its proper domain more clearly than his later disciples. Less gifted, more fervent, their very fervor leads to rigidity, misapplication, oversimplification.
So, unfortunately, are many applications today of the Rational Model. Writing as recently as 2006, design researcher Kees Dorst has to admit,
Although there have been many developments since then, the original work on problem solving and the nature of ill-structured problems, written by Herbert Simon, still looms large in the field of design methodology. The rational problem-solving paradigm, based on the conceptual framework that Simon introduced, is still a dominant paradigm in the field.13
Indeed so! In the field of software engineering, we all too often still slavishly follow the Waterfall Model, our own embodiment of the Rational Model.
Verein Deutscher Ingenieure Standard VDI-2221
The Verein Deutscher Ingenieure in 1986 adopted the Rational Model, essentially as set forth by Pahl and Beitz, as an official standard for German mechanical engineering.14 I have seen many rigidities in thinking engendered by this move. But Pahl himself has been at some pains to clarify that
Procedures given in VDI-Richtlinie 2221-2223 and Pahl & Beitz (2004) are not of the “straight sequence” type, but should be utilized only as guides for basic purposeful action. A useful approach in actual situations might be to choose either an iterative approach (i.e. with “forward and back” steps) or by repetition using the next higher information level.15
DoD Standard 2167A
Similarly, the U.S. Department of Defense in 1985 enshrined the Waterfall Model in DoD Standard 2167A.16 Only in 1994 did they, under the leadership of Barry Boehm, open up their acquisition by admitting other models.
So What? Does Our Design Process Model Matter?
Why all this fuss about the process model? Does the model we and others use to think about our design process really affect our designing itself? I believe it does.
Not Every Design Thinker Agrees with Me
Professor Ken Wallace of Cambridge, who translated three editions of Pahl and Beitz’s work into English, believes the major step forward is to have some model that is readily understood and communicated. He points out how useful it is for beginning designers. The Pahl and Beitz model gives novices a place to start work on a design, so they don’t just wander. “I put up the Pahl and Beitz diagram [their Figure 1.6] and explain it. And then my very next slide says, ‘But this is not the way real designers work.’”17
Hooray! But I am concerned whether younger teachers with less personal design experience always say that.
Suzanne and James Robertson, consultants who practice internationally and authors of excellent major works on requirements formulation, also feel that the deficiencies in the Rational Model don’t really matter. “People who understand what design is, know better.”18
Nevertheless, I believe our inadequate model and following it slavishly lead to fat, cumbersome, over-featured products and also to schedule, budget, and performance disasters.
Right-Brained Designers
Designers are mostly right-brained people, visually and spatially oriented. Indeed, one of my curb-stone tests for potential design talent is to ask, “Where is next November?” When my listener is puzzled, I elaborate, “Do you have a spatial mental model of the calendar? Many folks do. If you do, would you describe it for me?” The strong candidates almost always have one; the models themselves vary wildly.
Similarly, software design groups invariably scrawl diagrams, not words or code, on their shared whiteboards. Architects consider the broad-pen sketch on tracing paper an indispensable tool for communication, but even more for solo thinking.
Since we designers are spatial people, our process models live deep in our minds as diagrams, whether Pahl and Beitz’s vertical rectangle, Simon’s tree, or even the waterfall Royce draws and condemns. The diagrams subconsciously influence much of our thinking. Hence I believe a deficient process model hinders us in ways we cannot fully know and can barely suspect.
One obvious injury done by accepting the Rational Model is that we mis-educate our successors. We teach them modes of working that we ourselves do not follow. Hence we leave them unaided in arriving at their own real-world working modes.
I doubt if this is the case with more senior teachers, particularly those with industrial designing experience. We are keenly aware that models are intentional oversimplifications to help us with real-life problems that are frighteningly complicated. So we warn our students that “the map is not the terrain,” the model is not a complete picture; it may even be inaccurate in what it does incorporate.
In software engineering practice, another kind of harm can readily be spotted—the Rational Model, in any of its forms, leads us to demand up-front statements of design requirements. It leads us to believe that such can be formulated. It leads us to make contracts with one another on the basis of this enshrined ignorance. A more realistic process model would make design work more efficient, obviating many arguments with clients and much rework. Chapters 4 and 5 elaborate on the requirements problem.
The Waterfall Model is wrong and harmful; we must outgrow it.
Notes and References
1. The engineer needs a satisficing solution; the scientist needs a discovery, and wider exploration often yields one.
2. Blaauw and Brooks [1997], Computer Architecture, 26–27, 79–80.
3. Parnas [1976], “On the design and development of program families,” explicitly treats the design process as tree traversal. He argues strongly for making a design as flexible as possible. He urges that one do that by putting the decisions least apt to change nearest the tree root. Flexibility of a design is an important goal. In software engineering, both object-oriented design and agile development methodology have this as a fundamental aim. See also Parnas [1979].
4. Schön [1983], The Reflective Practitioner, 79.
5. Surprisingly, I found few critiques of the Pahl and Beitz formulation of the Rational Model and many of Simon’s formulation. Pahl and Beitz themselves recognized the inadequacy of the model: in successive editions of their work, their model (Figures 3.3, 4.3 in the second and third English editions) includes more and more explicit iteration steps (Pahl and Beitz [1984, 1996, 2007], Engineering Design). Simon’s three editions of The Sciences of the Artificial do not reflect any change in the model as proposed, although in personal conversation with me in November 2000 he said that his own understanding of the model had evolved, but that he had had no opportunity to rethink and rewrite accordingly.
Visser [2006], The Cognitive Artifacts of Designing, has an excellent Section 9.2, “Simon’s more nuanced positions in later work,” which examines Simon’s evolution as embodied in later papers. Visser shares my surprise that this evolution didn’t get reflected in the later editions of The Sciences of the Artificial.
6. Holt [1985], “Design or problem solving”:
There are two distinct interpretations of engineering design. The problem-solving approach, popular in many tertiary institutions and with an emphasis on solving structured, well defined problems using standardized techniques, may be traced to “hard” systems thinking. The creative design approach, on the other hand, combines analytical and systems thinking with human factors in engineering design to create and take advantage of opportunities to serve society. This paper discusses the limitations of the problem-solving approach in dealing with many real world tasks.
7. Whereas Cross’s critique is empirical, Schön criticizes the philosophy underlying the Rational Model. He says that the Rational Model, as enunciated by Simon, is a natural outgrowth of a much more pervasive philosophical mind-set, which he calls Technical Rationality and identifies as a heritage of now-discredited positivism. He finds the underlying philosophy itself totally inadequate for understanding design, even though it has been institutionalized into most professional design curricula:
From the perspective of Technical Rationality, professional practice is a process of problem solving. Problems ... are solved through the selection, from available means, of the one best suited to established ends. But with this emphasis on problem solving, we ignore problem setting, the process by which we define the decision to be made, the ends to be achieved, the means which may be chosen. In real-world practice, problems do not present themselves to the practitioner as givens. They must be constructed from the materials of problematic situations which are puzzling, troubling, and uncertain. ... a practitioner must do a certain kind of work. He must make sense of an uncertain situation that initially makes no sense. ... It is this sort of situation that professionals are coming increasingly to see as central to their practice. ... Technical Rationality depends on agreement about ends.
8. A vivid example is Seymour Cray’s 1995 quote: “I’m supposed to be a scientific person, but I use intuition more than logic in making basic decisions.” http://www.cwhonors.org/archives/histories/Cray.pdf, accessed September 14, 2009.
9. Cross [2006], Designerly Ways of Knowing, 27.
10. Cross [2006], Designerly Ways of Knowing, 57. Dorst [1995], “Comparing paradigms for describing design activity,” has an especially good discussion of Simon versus Schön. Their journal article is reprinted in Cross [1996a], Analysing Design Activity. Dorst also shows that for the Delft II protocols, Schön’s model fits the observed designer behavior much more accurately.
11. Royce [1970], “Managing the development of large software systems.”
12. Schön [1983], The Reflective Practitioner, 45–49.
13. Dorst [2006], “Design problems and design paradoxes.”
14. VDI [1986], VDI-2221: Systematic Approach to the Design of Technical Systems and Products.
15. Pahl [2005], “VADEMECUM—recommendations for developing and applying design methodologies.”
16. DoD-STD-2167A tried to fix this but unfortunately put a waterfall diagram in a prominent place and left things pretty much as they were. MIL-STD-498 superseded 2167A and addressed the model problem. DoD has since superseded 498 by adopting industry standards IEEE/EIA 12207.0, IEEE/EIA 12207.1, and IEEE/EIA 12207.2.
17. Personal communication [2008].
18. Personal communication [2008].