Few individuals have had as much influence on the practice (as opposed to academic theory) of software development than Frederick P. Brooks, Jr. His experience as leader of the IBM System/360 computer and its Operating System/360, documented in The Mythical Man Month (Addison-Wesley 1975, 1995) continues to shape how we think about project management. It would be difficult to find a more cited paper than his "No Silver Bullet: essence and accident in software engineering" (Information Processing 1986, Proceedings of the IFIPS Tenth World Computer Conference, ed, H.-J. Kugler. Amsterdam: Elsevier Science, 1069-1076). The notion of a "silver bullet" as a single almost magical solution to difficult software and programming problems is an inescapable part of the vocabulary.

Brooks' latest book, The Design of Design (Addison-Wesley, 2010) extends his previous ideas and adds new insights into the nature and importance of design. It will, no doubt, come to be considered as an essential resource in any professional developer's library.

The book is subtitled, 'essays from a computer scientist,' and consists of 20 chapters that can be read as if they were stand alone essays, with each chapter being somewhat loosely coupled to the others. This is a good thing, because most readers will want to read this book chapter by chapter - not necessarily in order - and spend some time thinking about what has been said before proceeding. In addition to the essays, the book offers eight case studies, ranging from the design of a beach house to the IBM System/360 Architecture, illustrating some of the important concepts in the book.

Related Sponsored Content

Addison-Wesley has provided an excerpt from the book that includes the Preface, a Subject Index, and Chapter 6 - Collaboration in Design.

What is design? Dorothy Sayers (English writer and dramatist - quoted by Brooks) suggests that design has three phases: The formulation of conceptual constructs, implementation in real media, and interactivity with real users. Brooks notes that in his 'Silver Bullet' paper he talked about the first phase, the conceptual construct, as THE essential difficulty of software engineering. In 1986, however, the 'conceptual construct' seemed to have more to do with what was going on inside the computer as it executed its instructions; and in the new book, the concern shifts more to that of architecture and the appearance and interaction of the program artifact in its environment. It is interesting, that Brooks opens this chapter with a quote from Bacon:

[New ideas would come about] by connexion and transferring of the observation sof one Arte, to the uses of another, when the experience of several misteries shall fall under consideration of one mans minde.

which clearly talks about the value of cross-disciplinary inspiration and training. Brooks does not follow up on this notion, even in later chapters where he discusses how to 'create' great designers.

Several chapters are devoted to a discussion of models of design and design process. Here Brooks severely critiques the prevailing,"rationalist," model of design - the reader is most likely familiar with this as the 'waterfall method' - concluding, "the Rational Model is much too simplistic." Multiple flaws with the rational model are noted, including "perhaps the most devastating critique of the Rational Model, is that most experienced designers just don't work that way." (David Parnas is mentioned several times in the book, but not his famous paper, "The Rational Design Process: How and why to fake it," another scathing critique of the Rational Model.) Several other design models are considered, including:

Iterative evolutionary development, the closest Brooks comes to a discussion of agile methods.

Boehm's Spiral Model

And, open source, Raymond's "bazaar model."

The conclusion of this discussion: some process and model of that process is required for design - mostly for communication and to support collaboration - and that Barry Boehm's spiral model is the one Brooks finds most promising."

Other essays (chapters) in the book are focused on:

Collaboration and Team design, including issues raised by telecollaboration.

A discussion of "Rationalism" versus 'Empiricism' with Brooks asserting that he is an avowed empiricist.

The value of constraints. This essay echoes a lot of the "design" literature coming from industrial, product, and graphic designers. A design brief (the document used to start the design process) must be ambiguous enough to allow freedom of thought and expression, but must clearly define any constraints. Constraints limn the boundary within which creative and imaginative or innovative design thinking can take place.

A discussion of beauty and style.

Some notes on design techniques and practices that Brooks finds of value

"Requirements, Sins, and Contracts."

And, a wonderful story of why JCL (Job Control Language, for those of you that have not had the pleasure of working with mainframes) is perhaps, "the worst programming language, ever!"

Towards the end of the book, two chapters are devoted to the question of great designs and great designers. Brooks notes immediately that great designs come from great designers, not from great design processes. Brooks notes that the way we educate and train software professionals is not conducive to the development of great designers. He notes that one of the major obstacles to educating great designers is the absence of continued practice and critique. In this observation, Brooks indirectly acknowledges the educational critiques of others, notably Richard Gabriel, who compared his education as a poet with his Stanford Ph.D. in computer science and the almost total lack of practice, exemplars, and critiques in the latter.

InfoQ had the opportunity to submit some followup questions to Fred Brooks, the 'interview' to be included as part of this article. The Q and A:

Development projects have a lifecycle, whether the classic linear waterfall or iterative incremental (Agile). Is design something that occurs at a particular stage in this lifecycle or is it distributed across all phases?

It is concentrated in the first few cycles of iterative development, but some occurs on each iteration.

If design occurs at each development stage, does it have different form, substance, or essence at each stage?

Sure! In the first iteration, the overall architecture is the central issue. In successive iterations, the design effort focusses at an ever finer level, except for backtracking when one hits dead ends, or when one recognizes a change in the requirements or a new opportunity.

What role to constraints play in the design process. [Background to this question: Designers in other fields often rely on a "brief" - and they expect/need ambiguity in that brief in order to allow freedom to "design," but they need clear articulation of the constraints that define the target region in which the optimal design will be found.]

They shape both the overall architecture and, to a lesser degree, the detailing.

Are there distinctly identifable "errors" of design and can they be recognized as they occur? [Or, are such errors like bugs in code, too often found long after they are made?]

The big errors are made at the beginning and rarely recognized. If caught at all, it is usually after fielding. The lesser errors surface as soon as coding begins and shout out when the first real user tests a prototype.

Most designers think of their activity as being highly collaborative - at a minimum a collaboration of the customer the designer and the thing being designed, but more often involving a team. Would you agree that design is collaborative? And, if so, what are the consequences if the design team is geographically and temporally distributed? [Obviously, looking for parallels to the general challenge of software development in today's off-shoring environment.]

I devote two whole chapters on Collaboration and Telecollaboration. Yes, most of today's design involves teams. Design of general-purpose products, such as the iPad, does not involve collaboration with the customer. For the design of a custom product for one client, I am a super-strong fan of early, intense, frequent, and on-going user testing with prototypes and surrogates (such as virtual-environment models of buildings. I don't consider that collaboration between the user and the client in the design, however.

Do you have a short list, say six bullet point items, that would summarize the most important lessons your book offers to designers?

Study your predecesssors' works intently, to see how they solved problems. Try to figure out why they made the design choices they did; this is the most illuminating question to ask yourself. Study your predecessors' styles closely. This is best done by trying to sketch something in their several styles. Keep a "sketch book" in which you put ideas, designs, and pieces of designs, whatever your medium. When starting a design, write down your assumptions about the users and the uses. Design, design, design!

In your "Silver Bullet" article you talked about the "conceptual construct" and the immense difficulty of mere humans holding such a thing in their heads. Do you think the insights in your current book address and/or resolve the essential difficulty of the conceptual construct?

Address, certainly; resolve, certainly not.

In Chapter 3, you do a very nice job of critiquing the rational design process, especially as embodied in the Waterfall Method, and note that it is harmful and must be done away with. Do you have any insights into the persistence of this harmful model? Are humans just perverse? Is it management's fault even though the developers know better? Is there some cultural - at least in Western culture - biases that prevent us from going over the Waterfall?

Chapter 4 argues that the persistence of the Waterfall Model in software engineering (and it is not common in other design disciplines) is due to the desire to enter into binding contracts with specified requirements much too soon.

In Chapter 20 you critique our education system (gently, it is true) and suggest that designer's need to engage in "critiqued practice." Richard Gabriel has long advocated that computer science / software engineering programs should adopt the same kind of program as he experienced when obtaining is MA in Poetry. (He long before earned his Ph.D. in CS): Tons of practice (a poem a day at minimum), lots of critique (peer and instructor), diligent study of Master Poets and Master Poems, constant self-relfection, and periodic retrospectives. This seems to parallel your suggestions, so would you advocate that universities offer a Master of Fine Arts in Software?

No. Schön, in The Education of the Reflective Practitioner, argues the same thing with examples and particulars much more suited to design disciplines. All engineering programs should emphasize that approach.

What other areas of study would improve a graduate's ability to be a great software designer?

Algorithms and data structures is the most essential study. Computer hardware architecture. Application areas, especially business data processing, database techniques and data mining. Psychology, especially perceptual psychology, since the user is all-important.

The rational design process, indeed all of computer science and software engineering, have consciously adopted a fundamental model of the Universe - that of 20th century physics - a deterministic, mechanical, rational Universe. If that is the nature or reality, then the rational, search tree, model of a design process makes a lot of sense. If the universe is actualy a complex adaptive system the rational model fails. Have you gone far enough to lay at least a foundation for a process for the design / modification of complex systems, like culture or even the business enterprise?

I would not be so arrogant as to suggest any such thing.

IDEO is a very well known design firm, and its president, Tom Kelly, has written several books on design, design process, and design thinking. One of his best is the Ten Faces of Innovation where he identifies ten roles that are needed in every design team. (Anthropologist, Experimenter, Cross-Pollinator, Hurdler, Collaborator, Director, Experience Architect, Set Designer, Caregiver, and Storyteller.) if you have any familiarity with this work, should similar roles be present in software design teams and how might this be done?

I don't know the work. Sounds intriguing and useful.

You mention Christopher Alexander and his influence with Notes on The Synthesis of Form and A Pattern Language. Those represent the "rational Alexander" but Timeless Way of Building and his magnum Opus, Nature of Order, are far more "mystical." Does the "Mystical Alexander" play any role in your ideas about design and design process?

I have been influenced by The Timeless Way of Building.

Most of the attention to design in the realm of software is directed towards the artifact - the computer as it executes a program. A growing area of practice (but not yet academia) is concerned with "user experience design" - with the system, the ecology, in which the artifact is embedded. Do you have some specific suggestions for how user experience designers could benefit from your book?

I think the advice given above applies equally well to user experience design, except that a liberal education is even more important for this field than for software engineering.

Can you identify 3 Master Designers (any field) and 3 Master Software Designers, and 4 or five Master Designs. Exemplars we should all be studying and a short idea of why they are what they are?