Today on Blogcritics
Home » Books » Book Reviews » Book Review: The Design of Design: Essays from a Computer Scientist by Frederick P. Brooks, Jr.

Book Review: The Design of Design: Essays from a Computer Scientist by Frederick P. Brooks, Jr.

Please Share...Tweet about this on Twitter0Share on Facebook0Share on Google+0Share on LinkedIn0Pin on Pinterest0Share on TumblrShare on StumbleUpon0Share on Reddit0Email this to someone

In my professional career, I have attempted at times to go back to school and take a course here or there to learn new skills or reinforce practical knowledge. So far none of those attempts has gone all that well. Instead, I end up finding books to bolster those areas I want to know more about. One such book is The Design of Design: Essays from a Computer Scientist by Frederick P. Brooks, Jr.

Back in 1975, Brooks published a groundbreaking book about software project management called The Mythical Man-Month: Essays on Software Engineering which changed how many managers began to think about how to best use their human resources on software projects. The key idea was that more people added to a project does not make it go faster, and in fact will make the project fall even further behind. Though the idea of "more people = faster" still exists in some companies, most modern project managers understand Brooks' message.

The Design of Design takes a similar approach to explaining what design is and how we can achieve better, more effective designs. This book should be mandatory reading for any and all individuals involved in software projects. Through a practical approach, Brooks applies layer after layer to show what works, what doesn't work, and why. Then he provides case studies that go across different disciplines such as architecture, remodeling, computer system architecture, and operating system design.

He starts by defining design, taking the definition from the Oxford English Dictionary:  "To form a plan or scheme of, to arrange or conceive in the mind… for later execution." He then breaks it into the recursive phases of Idea, Implementation, and Interaction. As he says, "Implementation creates a space in which another cycle of design must be done. Thus Mozart Implemented his opera Idea with pen on paper. The conductor, Interacting with Mozart's creation, conceived an Idea of an interpretation, Implemented it with orchestra and singers, and the Interaction with the audience completed the process." Far too often I think we consider these steps in isolation, which simply isn't the way the world works.

He goes on to describes the Design Concept as providing the two main benefits of conceptual integrity and aiding in communication. Without using conceptual terms such as "elegant," "clean," and "beautiful" when describing items such as buildings, music, or the iPhone, how would we know what to strive for? And those concepts help us when we try to communicate our designs to others with common language.

As a software engineer, Brooks really got my attention when he started talking about the Rational Model, the Waterfall Model, and the Spiral Model of the design process. Engineers typically work through the Rational Model — starting with a goal, working through constraints, and using the best design to move forward into the next phase. Many upper managers I've worked with through the years have used the Waterfall Method, which forces engineers to write reams of documentation instead of doing what they do best — writing code. And then there's the Spiral Model from Boehm, which was first described in the late 1980s.

The Spiral Model, like Brooks' description of the phases of Idea, Implementation, and Interaction, is recursive. With multiple cycles to design and implement requirements, you get more and more focused on the requirements of a particular client or project, which provides a much more solid deliverable for review. When the review comments come in, you go through further cycles to get even more focused until the project is deemed complete.

Through the rest of the book, he provides multiple, well-documented examples from his own experience on the IBM System/360 Computer and other projects over the last 50 years. Working in teams, dealing with user models and constraints, and even the use of style by designers are covered in detail. The breadth of that knowledge comes through loud and clear as he talks about military contracts for helicopters, many software and hardware projects, and even working on his own house.

But for me it's the seven Case Studies which make up the majority of the end of the book that really drive home the lessons he's learned. He breaks each down into a repeated pattern of introduction, objectives, opportunities, constraints, design decisions, and lessons learned, which makes it easy to compare studies to each other and apply some of the rationales and results to other disciplines and projects.

The Design of Design: Essays from a Computer Scientist by Frederick P. Brooks, Jr. is not a book for a casual afternoon of reading, but one to be read a few times to understand the nuances and practices described. It's also not a one stop shop for answers, but may perhaps inspire myself and others to ask different questions and help us tackle tough projects in our own careers! If you're in the computer field and deal with software, this should be on your Must-Read list.

Powered by

About Fitz

Fitz is a software engineer and writer who lives in Colorado Springs, CO, with his family and pets, trying to survive the chaos!
  • http://marksaleski.com Mark Saleski

    most modern project managers understand Brooks’ message

    yes, but folks in the management chain above the pm do not.

  • http://writer.fitzhome.com Fitz

    @Mark Saleski – I have to agree to some extent. I’ve worked largely in big corporations and sometimes I’ve been lucky with upper management getting it and other times not. As with everything in life, there’s a balance between progress and congress. :)

  • http://marksaleski.com Mark Saleski

    yes, well…we know why it happens. it looks like something important is going to be late and pressure is applied to “do something”. sadly, that “something” could have been dealt with early on in the project with better analysis of requirements and more conservative (read: realistic) schedule estimates.