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.
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?
I don't think we should all be studying the same exemplars. Deep study of an exemplar requires an education in the fundamentals of that exemplar's design discipline for one to appreciate the design problems and their solutions. Even laymen can appreciate consistency, unity of design concept, however.
- J.S. Bach, compositions
- Rembrandt, paintings and drawings
- Seymour Cray, supercomputers
- Christopher Wren, buildings, especially his London churches.
- Nicholas Wirth, programming languages
- Donald Knuth, algorithms
Community comments
Leonardo?
by Igor Kolomiets,
Beware of Analysis Paralysis
by Mike Gale,
Re: Beware of Analysis Paralysis
by Adam Nemeth,
Re: Beware of Analysis Paralysis
by Mike Gale,
Re: Beware of Analysis Paralysis
by Adam Nemeth,
Is design rationalistic only? Not, Software Engineering too!
by Jesús Zavala-Ruiz,
Re: Is design rationalistic only? Not, Software Engineering too!
by Adam Nemeth,
Re: Is design rationalistic only? Not, Software Engineering too!
by Jesús Zavala-Ruiz,
Re: Is design rationalistic only? Not, Software Engineering too!
by Adam Nemeth,
Book Review
by tushar jain,
Leonardo?
by Igor Kolomiets,
Your message is awaiting moderation. Thank you for participating in the discussion.
> Rembrandt, paintings and drawings
Why not Leonardo?
Beware of Analysis Paralysis
by Mike Gale,
Your message is awaiting moderation. Thank you for participating in the discussion.
In big teams you may need to follow prescriptive advice, but not so much in small teams or if you're working alone.
I find that overthinking about design can get in the way of actually doing it.
I imagine the book may be very useful for thinking about his observations and comparing to your own. The reviewer suggests that's a good way to use it. I'd however caution against the common path of thinking deeply about design rather than doing it. (Analysis Paralysis can tend to zero output in infinite time if you let it.)
Is design rationalistic only? Not, Software Engineering too!
by Jesús Zavala-Ruiz,
Your message is awaiting moderation. Thank you for participating in the discussion.
Why not to think that the devastating critique that does Brooks to the design actually is applicable to what commonly we consider to be the "software engineering"? Perhaps, the same rationality that arguye in the definition of software engineering is a myth, because in practice, the things do not are done like that it mandates? I think that it is completely valid. See: Nathan Ensmenger, “From 'Black Art' to Industrial Discipline: The Software Crisis and the Management of Programmers.” Ph.D. Dissertation, University of Pennsylvania, 2001. (Jesus Zavala-Ruiz)
Re: Beware of Analysis Paralysis
by Adam Nemeth,
Your message is awaiting moderation. Thank you for participating in the discussion.
True, but you know...
The zero level of software is what runs.
The first level of software is that it does what it is required to do.
The second level of software is that if you open it up, you don't say "oh my..."
The third level is some kind of conceptual clarity, which can follow the shape of changes easily.
Most people who think design isn't important create first-level software.
What I would argue, is that the first level isn't the last interesting one.
Third level is an art. I like that art, both observing, and trying to fulfill.
Re: Beware of Analysis Paralysis
by Mike Gale,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Adam.
I agree with your comment about conceptual clarity. When you see it it's beautiful.
I'm suggesting that the meta thinking of how do I create a good design can get in the way of actually achieving that good design.
Re: Beware of Analysis Paralysis
by Adam Nemeth,
Your message is awaiting moderation. Thank you for participating in the discussion.
You know, I had to learn Control System Theory at university. Think of it like the thermometer in a room.
How do these work?
First, it's cold... and the control system realises it, and it gets warmer. Then, it does overshoot. Then it leaves it to cold out. Then it gets too cold. Then it overshoots again, just a little.
(Much more picturial: upload.wikimedia.org/wikipedia/commons/3/33/Ove... - 3rd diagramm)
I did overshooting a few times. Maybe I'm just doing one right these days :) But I know that it's going to be okay, maybe I'll have some rows again for using cutting edge again (which means, youger than 4-5 years)
Also, after these overshooting, I was too relaxed, and zero-level code slipped out of my hands, after which I felt terrible. It ran, but it didn't do what it was intended to do, or did have side effects / performance issues, or were rejected at UAT.
This is balancing. Engineers do balancing each and every workday. It's a very rare situation when something has an exact and perfect solution from every angle: you balance between factors.
I wouldn't say overshooting is bad. Yes, it's bad there and then, true. We should try to avoid it.
But if you don't overshoot sometimes, it means that your stuff is always a little-little bit colder than requested.
Re: Is design rationalistic only? Not, Software Engineering too!
by Adam Nemeth,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hello,
Is there any non-paywall version of that article? A friend of mine asked for it, and I'd be interested too.
Re: Is design rationalistic only? Not, Software Engineering too!
by Jesús Zavala-Ruiz,
Your message is awaiting moderation. Thank you for participating in the discussion.
Dear Adam,
For me, there has not been an author who has impressed me so much as Fred Brooks for his affirmations so full of wisdom about project management and software engineering (SE) (whatever that it would be).
Obviously, not in a arrogant way, in my opinion SE it is not what has been stated to be or at least not in its IEEE's classic definition and this Fred Brooks' book goes in this direction although he pushes it back. And this devastating critique to the rationalist design and to the "sacrosanct process" ("holly"?, sorry because my bad English ;) ) is huge: "...great designs come from great designers, not from great design processes..." and perhaps, him the same critique is time to apply to the same engineering of software.
Why is my opinion in this way? Because the model of any organization which is converted in software, models an "organizational" (social) group but it's far away a "mechanicistic" or deterministic system, it's a complex adaptive system, but with a particular element: the human beings. Then all the attempts of control fail because in the human work, small innovations are made when it´s improved and skills is gained, every day. I wrote a paper on which I developed a more in-depth this idea. Look for first chapter in H. Oktaba & M. Piattini (eds). Software Process Improvement for Small and Medium Enterprises: Techniques and Case Studies.
Regrettably, the article "Is design rationalistic only? Not, Software Engineering too!" does not exist. It's my own conclusion of my recent research on software engineering and project management in progress. I'm applying a philosophycal framework for undertand SE as a whole.
Re: Is design rationalistic only? Not, Software Engineering too!
by Adam Nemeth,
Your message is awaiting moderation. Thank you for participating in the discussion.
(The article asked was the PhD you mentioned, sorry, used a wrong word)
Philosophy for SE is a nice stuff to do.
Let me put it in another context: for a while, I was on the social sciences department, as a researcher. I even studied social sciences.
The basis of social sciences is that people in large quantity will be act more-or-less predictably. In fact, it's not just people: the larger a thing gets, the predictable it is. It's the basis of economy as a science, for example. It does not say that everything is 100% predictable, but it's believed it has good enough solutions for some cases.
If you had read about physical architecture studies (buildings), you have learned that [build] architects the same about buildings as we say about software. The Windsor Castle is still in use, although the ages are really changed - it did not have to have toilets originally, for example. It's the organization of its inhabitants, to which a building needs to adopt.
Yet we came to realize that being able to build such a building requires a common set of studies, or, to say the least, it has sometimes advantage, if architects are forced to read what other architects before them thought about situations.
I sometimes argue this "every situation is different" stuff programmers are complaining about. Of course they are! But they're usually different in the same way!
I won't say it isn't needed to make a software inhabitable. i wouldn't argue innovation makes the world go forward. That innovation is about doing something unexpected. It's fine.
What I think what behind the idea is, that from the standpoint of engineering it does not really matters, if the world is rational or not. It does not matters because if software engineering isn't rational, then building engineering isn't one either. And it does not matters, because engineering is not about rationalism, it's about recognizing patterns and rules.
Let me quote the SWEBOK (freely available online at www.computer.org/portal/web/swebok/html/contents )
The IEEE Computer Society defines software engineering as: "(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1)."1
It does not say software is rational: what it does say, that:
- Software has patterns, therefore systematic solutions can be used for common situations
- Software can have methods to build, that means, there could be a discipline to build software
- Software has numbers associated with it (like: resource used, speed), therefore it can be measured, and optimized for it.
And another thing: the software engineering discipline is not about building wonderful software. It's about what could be a good average software. Software engineering was born when people realized that they need to do a LOT of software. The question is, if I have to do a lot of software, and a lot of people will do this lot of software, what do they have to have in common?
I think we have failed in that approach. Universities, schools aren't taken seriously. Of course, if they were, we wouldn't be able to change so rapidly, so on one side, it's a good thing. On the other side, I sometimes hate to tell people why do they need to do some practieces every time, and I hate maintain code where the architect wasn't strong enough to build such borders for his team.
Book Review
by tushar jain,
Your message is awaiting moderation. Thank you for participating in the discussion.
I have put my thoughts about book at my blog at architecture-soa-bpm-eai.blogspot.com/2010/05/b....