Home > Articles > Software Development & Management

Interview with Fred Brooks on the Publication of The Design of Design

  • Print
  • + Share This
Eoin Woods talks with Fred Brooks, author of The Mythical Man-Month, on what motivated him to write his new book, examples of good and bad programming languages, how to recruit great designers, and the three most important pieces of advice for managing design projects.
Like this article? We recommend

Eoin Woods: It’s been a long time since The Mythical Man-Month and its revision. What motivated your new book, The Design of Design?

Fred Brooks: Curiosity. The striking observation that all my own design experiences seemed to have a great deal in common caused me to ask and attempt to answer the questions:

  • What are those invariants?
  • Can the younger design disciplines learn from the older ones because of those similarities?
  • How has design changed since 1900?

Eoin: Your new book does talk about software design in places, but it’s really about design generally, and the case studies span buildings, organizations, hardware and software. Who is the book aimed at? Are you still writing primarily for people who design software or are you writing for a broader audience?

Fred: Definitely for a broader audience. I have been surprised that The Mythical Man-Month, aimed at software engineers, seems to have resonated with a broader audience. Even doctors and lawyers find it speaks to some of their team problems. So I aimed this one more broadly.

Eoin: You talk about designers and engineers in the book, but you subtitle it “Essays from a Computer Scientist.” Which are you? Engineer, designer, computer scientist or all three?

Fred: All three.

Eoin: What do you think the difference is between computer science and engineering?

Fred: I believe computer science to consist of two rather different sub-disciplines. One is a branch of mathematics, and produces theory. The other is concerned with making things, hence is a branch of engineering. We make systems, hardware, programs.

Eoin: Do you have favorite examples of good (or even bad) software design that you can share with us?

Fred: I consider Ken Iverson's APL programming language, after it morphed into J so it uses standard characters, to be a fine example of a programming language. In the book, I hold up and analyze the Job Control Language of OS/360 as a gruesome example of a bad language.

Eoin: In chapter 3, you make the point that we don’t really know what has to be designed until we’ve pretty well finished designing it. Does this mean that you’re an advocate of Agile approaches to software development?

Fred: Yes. But there is an important role for a system architect, even in Agile methodology. One wants the products to have conceptual integrity, for ease of learning, ease of use, and ease of maintenance and extension.

Eoin: How do you teach software design at UNC?

Fred: I've taught the software engineering course 22 times. I teach it as a critiqued project course, with teams of 3-5 (4 is ideal) working on a real project for a real client. The client has to invest sustained effort in helping the team define the product, of course. My rule is that a target product must be something that the client would find useful and like to have, but it must not be something the client has to have. The team must be allowed to fail.

Eoin: A particularly interesting part of the book talks about the need to recruit and develop great designers. Do you have any advice for people trying to recruit great software designers?

Fred: Look at their handiwork, not just how they talk about it! Yes, it is important to have the candidates explain rationale for their designs, but the excellence and elegance of the design itself is the test.

Eoin: The book contains a lot of explicit and implicit advice for those who must manage design projects. What would your top three pieces of advice for such managers be?


  1. Choose a chief designer separate from the manager and give him authority over the design and your trust.
  2. Plan for the iterative discovery and screening of requirements.
  3. Prototype (or simulate with models, etc.) early and get real user feedback on real use scenarios early and often.

Eoin: Lastly, your beach house is a rich source of case studies … was it ever finished?

Fred: Yes, I'm enjoying it immensely even now. We defined it to be finished when we varnished the floors in '97. We started in '72 with a carpenter-built campable shell, closed in and with one working bathroom. We did all the rest while using it thoroughly: all interior walls and doors, walkway to the beach, the staircase, all the wiring, the remaining plumbing, cabinets, floors. It was a great family project! We all learned a lot of new skills. Now we and our grown children enjoy it and do maintenance. Salt spray is aggressive and destructive.

  • + Share This
  • 🔖 Save To Your Account