Design of Design, The: Essays from a Computer Scientist

by Frederick P. Brooks Jr.

A chief service of a designer is helping clients discover what they want designed.

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

so scientists don't suffer from that sort of myopia?

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.

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.

Requirements proliferation must be fought, by both birth control and infanticide.

As for requirements creep, whether pressed by users or by internal inventors, schedule urgency had been the best defense.

It is generally assumed that collaboration is, in and of itself, a “good thing.” “Plays well with others” is high praise from kindergarten onward. “All of us are smarter than any of us.” “The more participation in design, the better.” Now, these attractive propositions are far from self-evident. I will argue that they surely are not universally true.

One sees this pattern—physical isolation, small teams, intense concentration, and leadership by one mind—repeated again and again in the design of truly innovative, as opposed to follow-on, products:

The most important single way to ensure conceptual integrity in a team design is to empower a single system architect. This person must be competent in the relevant technologies, of course. He must be experienced in the sort of system being designed. Most of all, he must have a clear vision of and for the system and must really care about its conceptual integrity.

If deciding what to design is the hardest part of the design task, is this a part where collaboration helps? Indeed so! A small team is much better than an individual at studying either an unmet need or an existing system to be replaced. Typically, several minds think of many different questions and kinds of questions.

reckon the design competition, originally suggested by Gene Amdahl, to have been immensely invigorating and fruitful. It put everyone hard to work again after a demoralizing cost estimate. It got each person deeply involved in all aspects of the design, which greatly helped morale and proved valuable in the later design development. It produced a consensus on many design decisions. And it produced a good design.

The review team should be much larger than the design team. Those who will build the design, those who will maintain it, sample users, those who will market it—all must be included.

If collaboration tools are designed so they encourage committee design, they will do more harm than good.

Once the exploratory stage is past and a basic theme is selected, it’s time for conceptual integrity to rule. A design flows from a chief designer, supported by a design team, not partitioned among one.

A classic 1970 paper by Torrance showed that dyadic interaction produced twice as many original ideas, produced ideas of twice as much originality, increased enjoyment, and led subjects to attempt more difficult tasks.

I am quite convinced that, once he has moved beyond questions that can be answered by reasonable inquiry, the designer should guess or, if you prefer, postulate a complete set of attributes and values, with guessed frequency distributions, in order to develop complete, explicit, and shared user and use models. An articulated guess beats an unspoken assumption.

wrong explicit assumptions are much better than vague ones. Wrong ones will perhaps be questioned; vague ones won’t.

Blaauw and I believe that consistency underlies all principles of quality. A good architecture is consistent in the sense that, given a partial knowledge of the system, one can predict the remainder.

Generality is the ability to use a function for many ends. It expresses the professional humility of the designer, his conviction that users will be inventive beyond his imagination and that needs may change beyond his ability to forecast. The designer should avoid limiting a function by his own notions about its use. When you don’t know, grant freedom.

Style is a set of different repeated microdecisions, each made the same way whenever it arises, even though the context may be different.

The designer should know well the exemplars of his craft, their strengths, their weaknesses. Originality is no excuse for ignorance.

Think at the top level about the object you are designing and its assumptions about the environment in which it will be used. Is a paradigm shift under way? Will your assumptions still be valid a decade hence? Are you designing the right thing?

Be careful how you fix what you don’t understand.

Design Isn’t Just to Satisfy Requirements, but Also to Uncover Requirements

Pyramids, cathedrals, and rockets exist not because of geometry, theory of structures, or thermodynamics, but because they were first pictures—literally visions—in the minds of those who conceived them.

Some will argue that broad exposure to exemplars will implicitly limit the designer’s creativity. Could the designs of a Brunelleschi, a Le Corbusier, a Gehry, a Gaudí, emerge from the minds of designers so indoctrinated? I submit that they did. None were amateurs. All trained by studying precedents. Like Bach, they innovated from mastery, not ignorance.

The whys, which cannot be captured from the action log, are crucially important for any complex design. They wonderfully aid refreshment after interruption. They remind one of the branching thought trails skipped as one explored a particular design alternative. The whys are priceless for new team members and for a designer’s project heirs.

like commit messages. although the failed attempts usually don't get recorded.

Since failure can arise from many causes, product processes typically demand consensus by many people, each expert in a separate cause of potential failure. Such consensus stifles great design in several ways. First, each expert watchdog is paid to avoid mistakes, not to make great things happen. So each is separately biased toward finding reasons not to proceed. Even when a really new product is not vetoed, consensus mechanisms often take off the sharp edges by forcing compromises. But the sharp edges are the cutting edges!

The engineers had always conscientiously and scrupulously followed IBM’s official Corporate Product Procedure, as documented in a manual of more than 100 pages. Successful project managers in other labs made bold “exceptions” to the procedure rules at the right times; the secret to success was choosing wisely!

Finally, consensus processes starve innovative design by eating the resource. Consensus building takes meetings, lots of meetings. Meetings take time, lots of time. Great designers are few and far between; their time is exceedingly precious.

product processes are, properly, designed for follow-on products. For innovation, one must step outside of process.

Product design and release processes cannot turn good designers into great ones. They rarely produce great designs without a great designer. But the disciplines imposed can bring up the low end of the design curve and improve the average performance of the art. That’s nothing to sneeze at.

The software engineering community has given much attention to its development processes. It has needed to, for I know of few design communities where average practice is so far behind best practice, and where worst practice is so far behind average practice.

Our right and fundamental democratic concern is that all people be equal before the law and, a much more difficult goal, have equal opportunity. But pursuit of these goals must not blind us to the wildly unequal distribution of native talents, and the unequal drives to grow, hone, and express native talent. Hence our structures and processes must cold-bloodedly recognize that people who have done great designs are more likely to make yet others if entrusted with freedom and authority to do so.

Since conceptual integrity is the most important attribute of a great design, and since that comes from one or a few minds working uno animo, the wise manager boldly entrusts each design task to a gifted chief designer.7 Entrusting has many implications. First, the manager himself must not second-guess the design. This is a real temptation, because the manager is quite apt to be a designer, but one whose design gifts may not be as great as the best who report to him (design and management are very different jobs), and one whose attention is surely fragmented among other tasks.

Make the Dual Ladder Real and Honorable The first task for growing designers, as opposed to managers, is to craft a proper career path for them, one whose compensation and sociological status reflect their true value to the creative enterprise. This is commonly called the dual ladder. I have treated this elsewhere; here I only repeat that it is easy to give corresponding salaries to corresponding rungs (and market forces tend to make that happen), but it requires strong proactive measures to give them equal prestige: equal offices, equal staff support, reverse-biased raises when duties change.

As these explorations proceeded, it became evident that the budgetary constraint, translated into 1,000 ft2, was inhibiting our thinking. So we decided to design to meet the objectives, then later cost-engineer and/or decide to spend more money if it then seemed worth it. This radically freed up our thinking. I have for some years advocated this approach to the design of computer graphics systems. In that domain, I had discovered that the best way to make a cost-effective application system is to make an effective one, then cost-reduce it, rather than making a cheap one and augmenting it until it is useful. It took me too long to come to this same approach on the house.

2. Talk many times, lengthily, with the principal user(s), showing prototypes they can understand. 3. Run lots of use scenarios.

Complete end-to-end single-error detection was mandated for all S/360 implementations, in spite of no evident customer desire to pay for such. This substantially helped in achieving the stiff reliability and maintainability goals.

Give the system architect full authority over the design

Some CEOs tend to fill board meetings with presentations, rather than discussions of real issues. Perhaps CEOs overestimate the untoward consequences of being overridden if a CEO takes a real issue to the board. Nor, in my experience, do many CEOs use their board members severally, as advisers in their areas of expertise. I think this a real loss.