| The Design of Design: Essays from a Computer Scientist / Frederick P. Brooks, Jr. | ||||
| Reviewed by Tal Cohen | Friday, 25 June 2010 | |||
In his new book, The Design of Design, Brooks attempts to describe “what do we really know about the design process”, and, more importantly, “what leads to effective, elegant designs”. Breaking away from the world of software, the book is explicitly aimed “for designers in every discipline”. “Brooks”, says the blurb on the back cover, “pinpoints constants inherent in all design projects and uncovers processes and patterns likely to lead to excellence”. After all the preliminaries and introductions, Chapter 2 comes as a shock: under the title “The Rational Model”, Brooks is basically describing what software engineers call “the waterfall model” — also known as the “have a detailed design before you start coding” approach. The chapter ends with a short and optimistic “What’s Right with This Model?” section, and... that’s it. The horror! Isn’t Brooks the one who told us to “plan to throw one away” (chapter 11 in The Mythical Man-Month [TMMM]), perhaps the granddaddy of agile-development advice? Why the sudden change of heart? Relief comes with Chapter 3, “What’s Wrong with This Model”, which outlines, in painstaking detail, why top-down, waterfall-style design is simply inappropriate for software design. So, good; Brooks is definitely being realistic. In most cases, software cannot, and should not, be designed like that — although Brooks laments that many software engineers still seem to stick with that approach. But there’s another conflict here. Is the book really “for designers in every discipline”, or is it really about software design, despite the author’s intentions? After all, the rational model is very reasonable for non-software projects, where “throwing one away”, or even just dynamically changing the design, can be a prohibitively pricey practice. Try as he might, Brooks seems unable to break away from his focus on software design, throughout the entire book. Yes, there are many examples and discussions about other kinds of design, based mostly on the author’s personal home and book design projects; and a few anecdotes from other design projects are also included. But all in all, one cannot avoid the feeling that this is a book by a computing professional, for computing professionals. A telltale sign is Chapter 28, “Recommended Reading”: out of fifteen recommended items, just three or four are not about computing. Most items will be of little or no interest to anybody outside the field of software engineering (how many architects will find interest in reading Computer Architecture: A Quantitative Approach, the classic textbook on hardware design?). The bibliography is not as narrowly focused, but still has a heavy software-engineering bias to it. This is a book about computer system engineering, after all. Having cleared that out of the way, how useful, interesting, or insightful is the book for software/hardware engineers? After all, none of us would be surprised by the inappropriateness of the waterfall model, which is considered broken for many a decade now. Is the rest of the book any better? This is not an easy question to answer. The book is a very enjoyable read, and its anecdotes and examples are often exquisite. My personal field of interest, for example, is programming language design, so the discussion of “The Worst Computer Language Ever” (which forms the bulk of Chapter 14), was an interesting one, albeit too short. The language discussed is JCL, originally developed under Brooks’ own supervision as part of OS/360. But wait: OS/360 was developed in the early 1960s; it was the cornerstone for Brooks’s experience, as detailed in TMMM in 1975. The JCL standard was published in 1965. Surely, there are newer examples? Newer, more relevant lessons to be learned? This is clearly the book’s weakest point. Newer technologies, methodologies, and design experiences are often mentioned — from the Macintosh desktop metaphor to Visual Basic (none really new, mind you) — but none is analyzed in detail, only mentioned in a passing. The deep case-studies (Chapters 21 through 27) include a house design example, house wing addition, kitchen remodeling, System/360 architecture, OS/360, book design (for a book about computer architecture), and one for the organization of a joint computing research center. Anything missing? Right, modern (as in, “from the past two or three decades”) examples in software design. I mean, each case study lists the “bold decisions” included in the design at hand, and we find there such gems as “base the architecture on an 8-bit byte” (for hardware architecture), and “incorporate multitasking” as well as “do not require [a human] operator” (for OS design). Bold, yes, but a bit rusty. Brooks attempts to highlight the core design concepts that outlive the specific system, and that are shared by all (software) design processes; these core concepts make his choice examples, old though they are, more relevant to modern practitioners. Much (though not all) of the lessons learned — which Brooks enumerates for each case study — are still valid, and so as a whole, the reading is educational and (at times) enlightening. But I still firmly believe that considering more recent designs, as well as more recent concepts in the world of design (e.g., design patterns), would have made the book far better. In other words, sticking to the olden days was simply a bad design decision.
| ||||
©1997-2022 by Tal Cohen, all rights reserved. [About]
