During one of the last discussions in my great papers in software engineering reading course Mary Shaw, our discussion moderator, casually alluded to a follow-up class in the next fall semester, "Fred sent me an early draft manuscript of a book he’s been working on about design. It’s shaping up really well and I might be able to convince him to let us use it as the centerpiece for another discussion course. I’d be willing to put a class together if anyone is interested. Let me know." Being a huge Fred Brooks fan I was one of the first people to sign up for the course. Throughout the fall of 2009 a group of professors, software professionals, and students met Wednesdays during lunch to talk about design and software engineering while reading Fred Brook's new book, The Design of Design, in addition to a few other design classics.
Putting software aside for a moment, designing anything is challenging even for experienced professionals. Simply understanding the problem that needs to be solved requires a great deal of effort. It’s rare that all the requirements for a project are known up front - so rare that I haven’t seen such a project since my sophomore year of college! Design is as much about understanding the problem as it is about finding a solution to that problem. As you’ve probably experienced many times, your boss always wants changes made to the software after you’ve shown him something that works.
Throughout The Design of Design Brooks wrestles with the idea that design is an iterative exploration of both the solutions and problems. The notion that everything can be known up front about a problem is absurd yet that’s the way people tend to want to build software. As Brooks writes, "The waterfall model is wrong and harmful; we must outgrow it." Amen, brother.
Design is not rational. Problems do not simply present themselves and from this, solutions flow forth. Instead, designs are born iteratively, initial problems beget partial solutions which lead to further insights concerning the problem and so on until a satisficing solution is reached – one that is, essentially, good enough for all intents and purposes. Of course, that assumes that the right intents and purposes were correctly understood and articulated.
Throughout the book, Brooks draws on examples from his own experience, some odd, such as the design of his dream home in Chapel Hill, others classic, such as the design of the O/S 360 Architecture. While Brooks' sudden realization that entertaining guests would be awkward in his newly designed home since there was nowhere "to put the coats" seemed out of place, stories like these made the abstract verb/noun/concept of design more concrete and relatable, even when considering software design. Besides, design is supposed to be fun.
The Design of Design is one of the most important books for software engineers since The Mythical Man Month. Unlike The Mythical Man Month, however I found that I had more questions than answers by the end of the book. The Design of Design made me feel more confident as a designer and software engineer but also more unsure of what to do next. The book is full of amazing, empowering ideas but very little that can be applied practically today. Many concepts I thought I understood suddenly revealed additional dimensions for my consideration, new ways of thinking about the world. I love it.
The Design of Design by Frederick Brooks is available now from Amazon.com. I highly recommend it.