The Design Of Design
Mediocre design provably wastes the world’s resources, corrupts the environment, affects internatonal competitiveness. Design is important; teaching design is important.
Fred Brooks, “The Design of Design”. Page x
Fredrick Brooks, the author of the “Mythical Man Month” and the project manager of the IBM System/360 (the most successful mainframe computer series back in the day), has written a new book called “The Design of Design”. Like “The Mythical Man Month”, it is a collection of essays, but in this one focus is on how good design can be achieved.
While computer-related projects are a main source of examples in the book, Brooks also draws from experience in designing buildings and other projects. The book is aimed at designers and project managers of many kinds, but computer science is clearly Brooks’s home discipline.
The essays are by no means how-tos trying to teach you a particular design process. Nor are there any singularly novel ideas you have never heard before, if you have some background in designing software. The value of the book is that it makes you think about the different aspects of design. The texts are well written and opinionated, inviting you to look at the issues presented in them from angles that are different from what you might be used to. In the rest of this post, I summarize some ideas that resonated with me, but I really recommend reading the book.
Fred Brooks (c) sd&m
The book is organized in six parts, I follow that structure for my notes here (not all parts are mentioned, however).
Models of Designing
The hardest part of design is deciding what to design
Page 22
In the first part of the book, Brooks explains that he rejects the waterfall model, because it is impossible to know enough about requirements and other factors influencing the design up front.
The Rational Model, in any of its forms [the waterfall model being one of them], leads us to demand up-front statements of design requirements. It leads us to believe that such can be formulated. […]
The Waterfall Model is wrong and harmful; we must outgrow it.
Pages 33,34
This is old news to anyone sympathizing with agile styles of design, but it is interesting to hear it from someone who worked on mainframes for IBM in the 50ies and 60ies.
The rejection of the waterfall model raises two questions: (1) why are project plans still often based on it and (2) what is a better model?
There are two plausible answers to the first question. It seems obvious, clean and strait-forward. But more importantly, most projects involve some sort of contract between the designer and the customer, where the customer would not be to happy about an open-ended, pay by the hour, it’s-done-when-it’s-done deal.
Brooks proposes decoupling the contracts for design from the contracts for implementation, but concedes that this is not a complete solution especially in software, where the boundaries between design and construction are blurry.
So what about a better model? The purpose of a model for design is to serve as a means of teaching and as map to answer the question “where are we?” in the course of a project.
Brooks has no definitive and final answer to this question, but he is in favor of something based on the spiral model proposed by Barry Boehm. In this model, development repeatedly go through stages of planning, determining requirements and contraints, prototyping, risk analysis, and verification.
Collaboration and Telecollaboration
In the second part, Brooks questions the notion that collaboration and design in teams are good per se.
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 are not universally true.
Page 64
Although there are good reasons from collaborative design such as technological complexity and time contraints, the challenge is conceptual integrity. As a consequence, Brooks argues that a design team should always have one system architect who calls shots in favor of a consistent concept.
Design Perspectives
The third part of the book contains essays with ideas that are similar to those of agile development.
Brooks starts with an interesting perspective on design where he compares different approaches to the philosophical schools of empiricism and rationalism. Rationalists believe that given sufficient experience and careful consideration, you can come up with a perfect design. The empiricist view on the other hand is that anything you design, no matter how well considered, will be flawed. The flaws need to be fixed by trial and error.
Brooks is clearly in the empiricist camp:
Can I, by sufficient thought alone, design a complex object correctly? No; testing and iteration are in practice necessary. But careful thought helps.
Page 109
An important factor for the design is the model you have of your product’s user. While it is impractical to know everything about the users, Brooks argues that you should explicitly state the assumptions you make in great detail, even if some of them are wrong.
Wrong explicit assumptions are much better than vague ones. Wrong ones will perhaps be questioned; vague ones won’t.
Page 117
Reminding me of 37signals he supports the notion that constraints are your friends.
Since constraints are the designer’s friend, if the task originally seems unconstrained, first think harder about what is really desired, about the user and use models, and you will probably find some narrowing constraints, to the benefit of both designer and user.
Page 135
Brooks than goes on to examine esthetics and style in technical design. In his analysis “logical beauty” comes from parsimony, structural clarity, and consistency. Parsimony roughly means “accomplishing a great deal with few elements”. Parsimony alone, however, is not enough. Without any redundancy, as design can be cryptic and infective.
According to Brooks, “consistency underlies all principles of quality.”
A good architecture is consistent in the sense that, given partial knowledge of the system, one can predict the remainder.
Page 143
Three design principles are important for consistency: orthogonality (do not link what is independent), propriety (do not introduce what is immaterial), and generality (do not restrict what is inherent).
Great Designers
In the fifth part, Brooks examines the value of design processes, individual designers, and education in design. He maintains that “great designs come from great designers, not from great design processes.”
I believe that standard corporate product design processes do indeed work against truly great and innovative design.
Page 233
This does not mean, however, that he is rejects processes entirely. The key is some middle ground where processes prevent grave errors, but are not followed to the letter stifling creativity.
First and foremost, the top leader of the organization must passionately want innovative products with great designs
Page 238
Concerning education, the most important idea in the book is that you should learn by critiqued practice, instead of getting taught the basics before starting to make stuff. Another component in learning is teaching to others. A third part in the education of a designer should be studying exemplars – designs by other designers.
