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 

Nip it in the bud or wait for the crisis

Twenty five years ago I was running an internal project for the consulting arm of Arthur Andersen & Co, back before it split off to morph into Andersen Consulting and then Accenture. We were creating a system development center to provide all of the development tools and facilities to support large scale information systems implementation projects. This was in the day when serious development was done on mainframe computers and setting up an environment for productive work could chew up a lot of time and fees without adding value for either Andersen or its clients. The centers turned out to be a successful venture for several years.

Setting up the first one was a large scale project management problem in its own right. Some challenges in creating a work plan and work breakdown structure for something that hadn’t been done before, but nothing out of the ordinary.

One odd conversation from that effort still sticks with me. It was early Monday morning, well before 8AM, and I was parked in the partner’s office. I had learned that the only way to guarantee Mel’s attention was to catch him before he got wrapped up in anything else. He rolled in a short time later and the conversation unfolded like this:

Me: I’ve been going over the project plans for the development center. We’re on track, but I’m worried about the scheduled install of the mainframe next month.

Mel: So?

Me: Do we deal with it now or wait until it’s a full blown crisis?

Mel: Wait until it’s a crisis

You need to understand that Mel was and is an excellent manager and leader. But I was certainly greatly puzzled at the time. Isn’t management supposed to be about anticipating problems and dealing with them before they get out of hand?

Consider some of the possibilities at this point, setting aside issues of organizational turf warfare or operating beyond your authority.

  1. Not all anticipated problems materialize. Calvin Coolidge’s observation about problems may apply, "If you see ten troubles coming down the road, you can be sure that nine will run into the ditch before they reach you."
  2. This is a management development opportunity. Someone who reports to you needs to recognize and deal with the problem. It can short circuit or undermine their development if you point out problems before they’ve had an opportunity to see them for themselves.
  3. A crisis can be put to good use. Allowing an issue to become more troubling and more visible may be a necessary step in garnering resources you may need later
  4. You or your organization confuses heroics with effectiveness. This is the dangerous case. If you’re confused, you can either get unconfused or seek out an occupation where heroics are relevant. On the other hand, if your organization (or your client) is confused that can be a serious problem. It takes an astute manager to recognize that "no muss, no fuss" indicates effective management. Or to distinguish between a real crisis and a manufactured one.

In my earliest managerial days, crisis was my too often default mode, out of ignorance and inexperience. Since then, I’ve learned to prefer bud nipping. More importantly, I’ve learned (and continue to relearn) that there aren’t many either/or choices in the real world. What strategies have you chosen when you see a problem on the horizon?