New Book by Fred Brooks - The Design of Design
amazon.com
amazon.com
Copyright
About the Author
Preface
Part I: Models of Designing
Chapter 1. The Design Question
Chapter 2. How Engineers Think of Design -- The Rational Model
Chapter 3. What's Wrong with This Model?
Chapter 4. Requirements, Sin, and Contracts
Chapter 5. What Are Better Design Process Models?
Part II: Collaboration and Telecollaboration
Chapter 6. Collaboration in Design
Chapter 7. Telecollaboration
Part III: Design Perspectives
Chapter 8. Rationalism versus Empiricism in Design
Chapter 9. User Models -- Better Wrong than Vague
Chapter 10. Inches, Ounces, Bits, Dollars -- The Budgeted Resource
Chapter 11. Constraints Are Friends
Chapter 12. Esthetics and Style in Technical Design
Chapter 13. Exemplars in Design
Chapter 14. How Expert Designers Go Wrong
Chapter 15. The Divorce of Design
Chapter 16. Representing Designs' Trajectories and Rationales: In collaboration with Sharif Razzaque
Part IV: A Computer Scientist's Dream System for Designing Houses
Chapter 17. A Computer Scientist's Dream System for Designing Houses -- Mind to Machine
Chapter 18. A Computer Scientist's Dream System for Designing Houses -- Machine to Mind
Part V: Great Designers
Chapter 19. Great Designs Come from Great Designers: Not from Great Design Processes
Chapter 20. Where Do Great Designers Come From?
Part VI: Trips through Design Spaces: Case Studies
Chapter 21. Case Study: Beach House "View/360"
Chapter 22. Case Study: House Wing Addition
Chapter 23. Case Study: Kitchen Remodeling
Chapter 24. Case Study: System/360 Architecture
Chapter 25. Case Study: IBM Operating System/360
Chapter 26. Case Study: Book Design of Computer Architecture: Concepts and Evolution
Chapter 27. Case Study: A Joint Computer Center Organization: Triangle Universities Computation Center
Chapter 28. Recommended Reading
Acknowledgments
Bibliography
For those of you who aren't familiar with the book, Brooks was the manager of IBM's huge OS/360 project in the 60s. The system eventually shipped, but it was massively overbudget and late. He took the lessons he learned from the debacle, and wrote 'Mythical Man-Month' in 1975.
It's shocking how many of his insights still apply: Adding people slows down projects. Keep teams tight, and structured around your most productive programmers. It often pays to think deeply about a problem before you tackle it. Don't overbuild.
It's true that dynamic programming languages, tools like git, and rapid prototyping have made some of his examples feel dated. However, the underlying principles are still solid.
Hopefully 'The Design of Design' is a similar goldmine. Even if it's only half as good as MMM, it's still earned a slot on my bookshelf.
... buy it already. Except for occasional references to kilobytes of RAM (what the heck are those? are they like gigabytes?), you'd think the book was written last week.
Among the things that has significantly changed since the 20th anniversary edition are:
(a) agile/incremental methods in software development are now widespread. In the book, Brooks present himself as a big advocate of what could be called proto-agile, contrary to the waterfall model of his time, and
(b) internet service companies flourishing in the internet. The "release early, release often" model could not be practiced anywhere better than in the internet, and this mindset has a great impact on how we think about the software development in general (note that at the Brook's times there were no internet services at all)
I haven't read anything of his that wasn't worth reading and the MMM is still one of the very best.
I found it very much worth buying the new MMM edition for his revisiting the "plan to throw one away, because you will" discussion on prototyping (e.g. see Joel's discussion on this). Very useful to me since I'd by then experienced most of the possible outcomes of this question.
He's not one to rest on his laurels and is to be commended for turning an epic disaster into a lifetime of suggesting to us with style and verve how we might manage to avoid such ourselves.