Fred Brooks is well known among computer scientists for (at least) two reasons: his work at IBM managing the development of the System/360 hardware and software, and his book describing that experience, The Mythical Man-Month (That book introduced Brooks's law: "Adding manpower to a late software project makes it later.") Brooks is a professor at UNC Chapel Hill where his research is focused on human-computer interaction and scientific visualization, especially in augmented and virtual environments.
Brooks has credibility with computer scientists, and this will likely be of importance for the impact of "The Design of Design," a collection of essays about design process in computer science (his work) and architecture (of buildings - his hobby). For readers familiar with the design research literature, the book may hold relatively few new insights and will re-present many common themes. But its target reader is not the design specialist; it's the software engineer and software team manager. With this reader in mind, the book succeeds as a cogent argument for the importance of paying attention to design process and getting that process right. Having this argument presented by a respected engineer, manager, and researcher in his no-nonsense style, illustrated with numerous examples of important, complex projects may carry the necessary weight for those skeptical of the fuzzy nature of design. This is a great book to hand to incoming CS graduate students and engineering colleagues.
To sum up the main arguments of the book: First, Brooks makes the case for iterative design. The "rational model" of design as a sequence of well-delineated stages (as found in Royce's Waterfall model and Simon's science of design) comes naturally to engineers; it mischaracterizes what actually happens in practice; it is thus harmful to real-world projects. Our ideas are incomplete and inconsistent before we attempt to realize them - thus requirements cannot be captured in the abstract. The role of design is to uncover requirements and to generate alternative strategies to meet those requirements. The project definition necessarily changes as we work on it; the process model must take this into account. Brooks points to Boehm's spiral and other models of iterative development with regular end-user involvement.
Second, the overall goal of design is to achieve conceptual unity across all aspects of a project. This is hard; design by committee never achieves it. Open Source design can achieve conceptual integrity - but it tends to do so only in domains where the builders are also the users (e.g., Linux). Brooks is unsure if Open Source works well as a methodology when designing for others, because of the incentive structures of the Open Source community (he strongly recommends reading Raymond though).
How can one achieve conceptual integrity in design teams, while leveraging the benefits of collaboration? Conceptual integrity requires having only one, at most two, main system architects and one, at most two, primary UI designers. However, more bodies are advantageous for uncovering needs and for design reviews. (For brainstoriming, "more minds mean more ideas. [...] the ideas are not necessarily better.") CSCW research is misguided if it envisions equal-participation collaboration as it ignores synchronization costs. While many CSCW design tools have been proposed, few have succeeded in practice (with revision control and "track changes" the exceptions); thus, Brooks cautions against assigning PhD dissertation topics in collaborative design tools. I agree that a naive approaches to collaboration often fail; but I disagree that careful, grounded research by graduate students cannot rise to the challenge.
Chapters in the section on "design perspectives" examine rationalism versus empiricism as fundamental stances toward design; the role of limited resources and constraints; "style" in engineering design, and the role of exemplars. Brooks points out that the prevalence of the rational view (careful planning and reasoning alone can yield the right design) is unique to computer science; all design disciplines that deal with the vagaries of the physical world necessarily rely on testing and iteration because of the limitations of their formal methods. However, taking an empirical stance to design does not relieve the designer of the responsibility of careful thought and planning. Constraints are welcome, because it is easier for a designer to exercise restraint when designing for a narrow purpose than a general one.
What defines style in design? Parsimony (economy of expression) is often an ingredient, but it alone is insufficient. For example, a minimal instruction set might be Turing-complete, but it does not support any one concrete task well. Beyond concision, then, "structural clarity" is required: it "demands that the basic structural concept of the design be plainly evident and, if not logically straightforward, easily explained." Style in engineering design is "a set of different repeated microdecisions, each made the same way whenever it arises, even though the context may be different." Style is hard (and voluminous) to explicitly specify, this is one of the reasons that coherent style in group design is rarely achieved. While documentation of style is not trivial, Brooks argues strongly for doing so. This raises the question: how might documentation of a design style be facilitated?
The chapter on the role of exemplars in design was of special interest to me as example-centric development has been a research focus of mine (see d.mix, HelpMeOut) and of colleagues. Referring to exemplars in design has important benefits (the "provide safe models for new designs, implicit checklists of design tasks, warnings of potential mistakes, and launching pads for radical new designs.") The use of exemplars in software design lacks in comparison to other disciplines, which Brooks laments. Novices and experts may draw upon different sets of exemplars: novices tend to use ones encountered in their immediate experience, while experts refer a much larger set of historical precedents. Our scholarly literature often does a poor job at explaining the rationale for design decisions in software systems - thus papers are of limited use as design exemplars. However, conveying rationale is what really matters. (For research, this suggests that merely showing related exemplars without proper explanation of why they are shown may not be sufficient.) The systematic collection and cataloging of exemplars should be encouraged (but doesn't count as research in technical disciplines). Beyond collection, exemplars should be critiqued and compared to others. But, does reliance on examples lead to laziness and restrict originality? Brooks answers that one should not design by merely copying and adapting exemplars, but by deeply understanding their rationale and transferring the approach, rather than the surface structure. He concedes that "the world is full of lazy Bauhaus architecture and mediocre ranch-type homes" but argues that the fallacy of their architects was a too near-sighted in use of exemplars.
The later sections of the book were less central to Brooks' argument, and to my interests. A historical note describes how the profession of design is characterized by its divorce from making, as well as from using, the designed artifact. This means that designers have to work hard to understand the perspective of both the implementer and the final users, as neither come naturally. A chapter on the attempted capture of design rationale during the process of design (of a house) concludes that such a project is rather complicated, and that current tools are not much help. The book concludes with a set of case studies which answer his own call to capture and describe design rationale through collections of exemplars. However, they are also very specific to the design of houses, organizations, books. To me then their value is in demonstrating the possible format of rationale descriptions.
One surprising aspect of the book is the repeated use of Biblical references in the prose. These tend to detract from Brooks' otherwise sound arguments for those of us of alternative persuasions.
]]>
