Fred Brooks on the Design of Design

The Design of Design: Essays from a Computer Scientist, Brooks, Frederick P.

Currently a professor of computer science at the University of North Carolina, Fred Brooks led the development of IBM’s System/360 and its operating system. He’s the author of The Mythical Man-Month : Essays on Software Engineering, which remains one of the best books on project management in the real world. In The Design of Design,  Brooks reflects on what he has learned about the problems of design over the course of his long and distinguished career. He combines his reflections with case studies drawn from multiple design efforts. Here is his justification for adding one more volume to the growing literature about design:

the design process has evolved very rapidly since World War II, and the set of changes has rarely been discussed. Team design is increasingly the norm for complex artifacts. Teams are often geographically dispersed. Designers are increasingly divorced from both use and implementation — typically they no longer can build with their own hands the things they design. All kinds of designs are now captured in computer models instead of drawings. Formal design processes are increasingly taught, and they are often mandated by employers.

…

I believe a "science of design" to be an impossible and indeed misleading goal. This liberating skepticism gives license to speak from intuition and experience — including the experience of other designers who have graciously shared their insights with me.  [The Design of Design, pp.xi-xii]

Brooks begins with a look at various rational, engineering-centric, models of the design process including Herbert Simon’s view of design as a search process and various waterfall models of software development. His take, and mine, is that these models bear only a passing resemblance to how real designers actually do design. Whatever value they might have as reminders to experienced designers is outweighed by the risks they pose in the hands of those without the necessary experience base to appreciate their limitations.

Brooks frames the design process problem this way:

  • If the Rational model is really wrong,
  • If having a wrong model really matters, and
  • If there are deep reasons for the long persistence of the wrong model,

then what are better models that

  • Emphasize the progressive discovery and evolution of design requirements,
  • Are memorably visualized so that they can be readily taught and readily understood by team and stakeholders, and
  • Still facilitate contracting among fallen humans?  {p.52]

Brooks thinks that something along the lines of Barry Boehm’s Spiral Model of software development will best meet these criteria.

In the middle section of his book, Brooks explores a variety of topics and issues relating to design including

  • when collaboration is useful vs. when it is not
  • conceptual integrity
  • identifying the core budgeted constraint (rarely money)
  • finding and developing great designers

In the final section, Brooks examines several cases in depth.

As a series of essays and reflections, this book is most valuable to those who have wrestled with design problems of their own. Given the frequency with which all of us are presented with design problems, Brooks’ reflections on real design problems offers many useful insights. Among the insights that I will be mulling over:

  • the boldest design decisions, whoever made them, have accounted for a high fraction of the goodness of the outcome
  • great designs have conceptual integrity–unity, economy, clarity. They not only work, they delight.
  • An articulated guess beats an unspoken assumption
  • wrong explicit assumptions are much better than vague ones
  • If a design, particularly a team design, is to have conceptual integrity, one should name the scarce resource explicitly, track it publicly, control it firmly