2. How Engineers Think of Design—The Rational Model
A Rational Model of the design process
• Goal
• Constraints, especially budget (perhaps not $ cost)
UNTIL (“good enough”) or (time runs out)
DO another design (to improve utility function)
UNTIL design is complete
WHILE design remains feasible,
make another design decision
END WHILE
Backtrack up design tree
Explore a path not searched before
END UNTIL
END DO
Take best design
END UNTIL
... [F]or the theory of design is that general theory of search ... through large combinatorial spaces.
HERBERT SIMON [1969], THE SCIENCES
OF THE ARTIFICIAL, 54
The Model
Engineers seem to have a clear, if usually implicit, model of the process of design. It is an orderly model of an orderly process as the engineer conceives it. I shall illustrate with an example of a beach house design (sketched in Chapter 21).
Goal
First one starts with a primary goal, or objective: “One wants to build a beach house to take advantage of wind and wave at an oceanfront lot.”
Desiderata
Associated with the primary goal are a host of desiderata, or secondary objectives: “The beach house should be reinforced to withstand hurricane-force winds; it should sleep and seat at table at least 14 people; it should exploit the stunning views;” and so on.
Utility Function
One wants to optimize the design according to some utility or goodness function that weights the several desiderata as to their importance. So far as I can tell, most designers imagine the terms themselves to be linearly summed, but conceive of each goodness variable individually as not linear, but rather as curved asymptotically to saturation. For example, more window area is a desideratum, something desired in house design. But the utility added by each extra square foot of window diminishes. The same is true of electrical outlets. The utility of the windows and that of the outlets, however, seem simply to sum.
Constraints
Every design, and every optimization, is subject to constraints. Some of these are binary, either satisfied or not—“The house must be set back at least 10 feet from the lot’s side lines.” Others are more elastic, with steeply rising penalties as one approaches a limit, such as schedule constraints—one fiercely wants to have the beach house ready when warm weather comes.
Some constraints are simple, such as setback limits. Others blithely conceal terrifying complexity—“The house must satisfy all the building codes.”
Resource Allocations, Budgets, and Crucial Budgets
Many constraints take the form of a fixed resource to be allocated among design elements. The most common is a total cost budget. But this is by no means the only such constraint, nor is it necessarily the one that most controls the designer’s attention in a particular project. In the beach house floor plan, for example, the controlling commodity to be rationed was the feet (even inches) of ocean frontage. In the design of a computer architecture, the critical budget may be the bits in a control register or an instruction format, or the uses of the total memory bandwidth. When people were solving Year 2000 problems in software, working days on the schedule were the crucial allocable resource.
Decision Trees
Now, so the Rational Model goes, the designer makes a design decision. Then, within the design space narrowed by that decision, he makes another.1 At each node he could have taken one or more other paths, so one can think of the process of design as the systematic exploration of a tree-structured design space.
In this model, design is conceptually (at least) very simple. One searches the tree-structured design space, testing each option against the constraints for feasibility and choosing so as to optimize the utility function. The search algorithms are well known and can be cleanly described.
That cleanliness holds only for an exhaustive search of all paths, seeking a truly optimal solution. Designers commonly satisfice by searching only until a “good enough” solution is found.2 Many engineers seem to approximate some sort of depth-first search strategy, choosing at each node the most promising or attractive option and exploring it to the end. At dead ends, one backtracks and takes another path. Hunches, experience, consistency, and esthetic taste guide each option selection.3
Whence Formulations of This Model?
The notion that the design process should be modeled as a systematic step-by-step process seems to have first developed in the German mechanical engineering community. Pahl and Beitz present the most widely used exposition in seven successive editions of their great work.4 They observe the practice, but not the explicit statement, of systematic search of design alternatives in the Notebooks of Leonardo da Vinci (1452–1519).
Herbert Simon independently argues for design as a search process in The Sciences of the Artificial [1969, 1981, 1996]. His model and his discussion of it are much more sophisticated than those here. Simon, optimistic that the design process was a fit target for artificial intelligence (once adequate processing power became available), was motivated to lay out a strictly rational model of design precisely because such a model was a necessary precursor to automating design. His model remains influential even if today we recognize the “wicked problem”5 of original design as one of the least promising candidates for AI.
In software engineering, Winston Royce, appalled at the failures of the “just write it” approach for large software systems, independently introduced a seven-step Waterfall Model to bring order to the process, as shown in the next chapter’s frontispiece. In fact, Royce introduced his waterfall as a straw man that he then argued against, but many people have cited and followed the straw man rather than his more sophisticated models. I made that mistake myself in my younger days, and publicly repented of it later.6 Even if ironically, Royce’s seven-step model must be considered one of the foundational statements of the Rational Model of design.
As Royce emphasizes, his seven steps are distinctly different from one another and must be planned and staffed differently. Iteration is provided for but carefully limited in scope:
The ordering of steps is based on the following concept: that as each step progresses and the design is further detailed, there is an iteration with the [immediately] preceding and succeeding steps but rarely with the more remote steps in the sequence. ... What we have is an effective fallback position that tends to maximize the extent of early work that is salvageable and preserved.7
The notion that a design space can be formulated as a tree is implied by Simon. It is described and illustrated by Gerry Blaauw and me in our Computer Architecture.8 There we arrange the design choices for processor architecture strictly hierarchically in a giant tree, represented by 83 linked subtrees. A simple example of the decision tree for the alarm of an alarm clock is shown in Figure 2-1. In it one observes two types of branches indicated by open and closed roots. The first, as shown for “Alarm,” shows a subdivision; each branch is a different design attribute that must be specified. This is called an attribute branch. The alternative branch, shown for “Sound,” enumerates alternatives of which one must be chosen.
Figure 2-1 Portion of a decision tree for an alarm clock
From Blaauw and Brooks [1997], Computer Architecture, Figures 1-12, 1-14.
What’s Right with This Model?
Any systematization of the design process is a great step forward compared to “Let’s just start coding, or building.” It provides clear steps for planning a design project. It furnishes clearly definable milestones for planning a schedule and for judging progress. It suggests project organization and staffing. It helps communication within the design team, giving everyone a single vocabulary for the activities. It wonderfully helps communication between the team and its manager, and between the manager and other stakeholders. It is readily teachable to novices. It tells novices facing their first design assignments where to begin.
The Rational Model in particular brings yet more advantages. The early explicit statement of goals, secondary desiderata, and constraints helps a team avoid wandering, and it breeds team unification on purposes. Planning the whole design process before starting coding or formal drawings avoids many troubles and much wasted effort. Casting the process as a systematic search of a design space broadens the horizon of the individual designers and lifts their eyes far beyond their previous personal experiences.
But the Rational Model is much too simplistic, even in Simon’s richly developed version. Hence we must examine its faults.
Notes and References
1. Following Simon [1981], The Sciences of the Artificial, throughout this book I use man as a general noun, encompassing both genders, and he, him, and his as androgynous pronouns. I find it more gracious to continue the long tradition of including women and men equally in these general pronouns than to adopt more awkward, hence distracting, constructions.
2. To satisfice is to make good enough without necessarily optimizing (Simon [1969], The Sciences of the Artificial, 64).
3. But see Akin [2008], “Variants and invariants of design cognition,” who finds evidence from the DTRS7 protocols that building architects tend to search laterally among several alternatives at every level, whereas engineering designers emphasize depth-first search based on an initial solution proposal.
4. Pahl and Beitz [1984ff.], Engineering Design.
5. Rittel and Webber [1973], “Dilemmas in a general theory of planning,” define this term formally. It is well discussed in http://en.wikipedia.org/wiki/Wicked_problem.
6. Brooks [1995], The Mythical Man-Month, 265.
7. Royce [1970], “Managing the development of large software systems,” 329.
8. Blaauw and Brooks [1997], Computer Architecture.