The Design of Designreviewed by Philip Greenspun; April 2010
Site Home : Book Reviews : One Review |
The Design of Design: Essays from a Computer Scientist is a new book by Frederick P. Brooks, Jr., author of perhaps the only good book on software engineering, The Mythical Man-Month.
The best part of the book concerns the quality of university education for software engineers and the process of creating more good designers. American universities are very consistent when it comes to admitting students with high IQs, collecting one hundred thousand or more dollars from each student, and giving nearly everyone who has occupied a chair for four years a bachelor's degree. What is inconsistent is the result of ths educational process. A minority of people with engineering degrees are able to do engineering; most are not.
In America most engineering designers spend most of their formal education in the classroom, or in the lab doing prescribed experiments, not doing designs to be critiqued. The same is even more true of software engineers. ... we are misusing the most precious commodity in the education process: student time.
Brooks includes an 11-page chapter on how individuals can improve their design proficiency, how employers can help young engineers develop, and how universities could improve (probably the least useful part, since universities have no incentive to improve!).
[Note: I've written on this subject myself in the following articles...
The book includes an 8-page chapter with some sensible advice about collaboration, e.g., schedule initial and periodic face-to-face meetings. Brooks talks about things that would make for better videoconferencing, such as better depth cues and higher resolution. I found it odd that he did not mention any of the following: (1) video displays that can show participants life-size, (2) Google Documents, (3) various Web-based and/or Wiki-like collaboration systems.
Brooks provides no detailed examples of how telecollaboration works or doesn't work and no guide to what sorts of documents are required. I would have hoped for something at least as detailed as my software design review process, but it isn't here.
The bulk of the book alternates between the very general, e.g., "What is Design?", and the very specific, e.g., "What were the requirements for the Brooks family beach house in North Carolina?" Neither of these are very useful for the working software engineer. Once you've learned what design is, what exactly should be done differently? The house in North Carolina sounds as though it worked out well, but what if you can't afford beachfront property? Of what value is learning about the house design?
Is it possible to write a great book about design in the abstract? Let's consider some of the greatest achievements in this area. Edward Tufte's books are generally considered the best things ever written on information design. Sometimes he gives specific advice on how to build certain kinds of systems, e.g., bar charts or Web-like computer-human interactions. But mostly Tufte selects examples of great design or finds terrible designs and shows how to improve them. The reader is forced to synthesize his or her own general principles, if indeed it is possible to find any across such a broad range of challenges.
A Pattern Language is 1171 pages of fairly small type and does not try to cover all design processes or fields. It presents one design challenge or design idea at a time and explains it. Again, if a grand synthesis is possible the reader is forced to undertake it for him or herself.
The Design of Design: Essays from a Computer Scientist does not add a lot to The Mythical Man-Month.
This book contains a fair number of figures and the reader may wish to skip/skim some chapters as well as flip back and forth. I think this book will work better in hardcopy than on an electronic reader.