Fred Brooks is known to most developers for his widely acclaimed 1975 software engineering book, “The Mythical Man-Month.” This slim volume presented a series of important lessons and insights derived in part from Brooks’ experience designing and implementing the IBM 360 mainframe and its operating system, OS/360.

Since that book came out, Brooks, who currently teaches computer science at the University of North Carolina at Chapel Hill, has won the ACM Turing Award (1999) and has intensively studied the process of design. The results of his investigations were recently published in a collection of essays entitled “The Design of Design” (Addison-Wesley, 2010).

Brooks took time out to discuss design and his new book with SD Times. Here are excerpts from the conversation.

The book

SD Times: What does “Design of Design” refer to?
Fred Brooks: For 15 years, I’ve been studying the invariants of design across media, so that we might learn something that will be useful regardless of what we’re designing. So this is not intended to be a software engineering book per se.

It seems that, as far back as 1999, you were working on this topic.
I gave the first talk on this topic 15 years ago, and I’ve been putting out an essay on it now and then ever since.

So, what led you to write this book? What unmet need did you try to fill with it?
I would say that there were two things. One is, as I have worked in various design tasks over the years, the thing that struck me was how much alike they were. So the question is, what then are the invariants that don’t depend on the medium of design, but are true of the design process? And are there lessons that the younger design disciplines (of which I am chiefly a practitioner) in hardware and software can learn from the older design disciplines by looking at their processes? So that was the motivating thing to start with.

The second thing was, how has design changed from the beginning of the 20th century to now? And the two big things are that people now design in teams for most things, and that raises a whole host of new complications; and, increasingly, the person doing the design cannot build the thing designed.

Henry Ford built his own car with his own hands in his own shop, and the Wright brothers were machinists who built their engine as well as their airframe. Today, this is done by other teams.

In the book, when you discuss the nature of good design, you frequently say that great designs are the product of great designers.
Great designs, yes, they do come from great designers.

Is an aspect of your thesis that there has to be a fundamental talent for design? Or can people who have no predisposing talent be trained to be good designers?
Good designers, yes. Great designers, I would say no. In other words, the Palm Pilot was a nice thing. The iPhone was a great thing. The BlackBerry is a nice thing; it’s a good design. But the iPhone is a great thing. And it comes fundamentally from Steve Jobs’ vision of what the product ought to be. He didn’t do the electronics, but he had the vision.

Conceptual integrity as the basis of good design

What is the key element of good design?

I start from the point of view that good design is characterized by conceptual integrity.

You discuss the need for design integrity in systems and subsystems. What happens when a change is made to the software that strongly affects the design integrity of the project?
Well, two things happen immediately. The first is that it becomes harder to learn, because you have to learn conflicting concepts, and which one applies when. And, secondly, it becomes harder to use for the same reason.

Is there a way to maintain design integrity and flexibility?
Yes. Ken Iverson did this all his life with APL. People kept proposing new things to put into APL, and he would figure out how to accomplish that with the things it’s already got, or else he would come up with a new version of the same thing that would achieve the function within the spirit and style of the existing product. Linus Torvalds and Andrew Morton do that today with Linux.

That integration is a crucial skill in project management, then.
Yes it is. And I’ve seen some people who really have it. The other crucial skill is to recognize that you want one mind or two minds acting in unison retaining that intellectual control. One of the mistakes that is often made is to move the designers onto something else and put second-rate talent on the maintenance and the extensions department. Then you get messes like [Microsoft] Word.

In general, I want a single chief designer. I want someone who’s responsible for conceptual integrity, because if multiple minds design it, it’s real hard for one user to get their mind around it.

In teams, that has to be one of the overriding challenges maintaining that conceptual integrity.
Yes. And so, when I was teaching a software engineering lab, I would tell the teams (typically consisting of four people), “Choose one person to be the boss and another one to be the technical director.” And I use the analogy of the producer and director of the film. One person is responsible for getting it done and another one is responsible for getting it right. And those are different functions, and the producer had better not interfere with the artistic concept of the director—that is, the designer.

Software design and agility

It seems to me from the book that you would be a big fan of agile software development.
Yes.

Much of what you say about other fields sounds like agile disciplines applied to those fields.
Yes.

For the agile model to work, one of the key elements, which I think is under-discussed, is the level of intelligent participation required of the user. The user has to be able to give intelligent feedback.
Not necessarily. Software has the advantage that it’s much easier to get the early prototype out and it’s not expensive. Consequently, you can do user testing much earlier.

You just can’t do it with a house, for example, except with some virtual reality where you do user testing with buildings. I did that on a church fellowship hall, and that helped us make some wise decisions. And we did that on our kitchen. But it’s very hard to prototype a building. People make scale models. That lets you get the esthetics, but it doesn’t let you run use scenarios very well, whereas with software you can run use scenarios.

But even if the user you’re designing for is a nurse in a ward who might not be able to give you useful insights about the user interface, videotaping what she does and watching it several times will give you useful insight. We learned that when we built a molecular graphics system. We videotaped the users on an early version and, looking at the videotape three or four times, we’d see things the fourth time that we hadn’t seen before: awkwardness, stumbles and whatnot that we could fix.

Communicating software design

In software design in particular, it seems like the primary notational representation is the UML.
Yes.

Working from the theory that any form of communication of ideas is hampered by the actual form of that communication…
Constrained, at least.

Yes, in that context, do you view software development as needing a richer notation?
My handicap is that I haven’t done any major software development with a team. I don’t have a well-developed instinct on that at this point. I haven’t done that kind of thing since UML came along.

Is there a frustration of the intent by the difficulty of communicating the specifics of design?
One of the things I notice is that no matter what people are designing (this is true of organizations; this is true of software), they draw. Even though drawing is, once again, a partial capture of your conceptual structure. People don’t write out designs; they don’t like to.
 
What is curious is that requirements are almost always stated as prose.
Yes.

Is there an impedance mismatch there?
I think so. But the difficulty is that requirements demand a certain precision for clarity, and prose gives you precision, whereas a whole lot of the drawing of diagrams that we do are way too vague. They’re wonderful for live, person-to-person, right-now communication. On the other hand, you copy that off a white board and you look back at that thing three months later and you wonder, “What is that?”

There is a lot of hand waving that is lost in a diagram.
Hand waving is very expressive. There’s a paper coming out of Reading, England on the function of hand waving in architectural design teams. I’ve seen a pre-draft of it, and the author is studying something that’s really important.

You mention in your book that when working on your house, you generated about 180 pages of notes, from which you extracted a design decision tree. In a recent speech by Kent Beck at the Enterprise Software Development Conference, he talked about keeping track of all the small design decisions he made while coding.
Good!

He said that he could only do that for two weeks, as it otherwise took too much time. What was the benefit you derived from going back over the 180 pages of notes?
Surprisingly little. It has to be considered an experiment that failed. But it’s still important to capture rationales for decisions.

Take, for example, the people at the airplane engine group at Rolls-Royce. They have the DRed [design rationale capture] system. DRed is owned by Rolls-Royce and BAE Systems jointly. The people at BAE don’t use it, but those at Rolls-Royce do.

The reason why Rolls-Royce does is interesting. They have a culture in which engineers had to write the rationales for engineering decisions in prose. So, when they got this electronic system, it made life easier, not harder. BAE didn’t have that tradition, so putting in a system that made people write down their rationales was perceived as more work, not less.

Rolls-Royce has found it valuable, for example, when you have the report of an engine failure. The people who are investigating the cause of the failure go back through these things and try to figure out where somebody doing a revision didn’t understand why things were the way they were to start with, and undid something that was crucial. We’ve seen that happen in software plenty of times. And so the Rolls-Royce people say that this is as useful for maintenance and for investigating engine failure reports as it was for justifying the decisions to management and to each other in the original design process.

In all software models, it seems to me there’s very little capture of the rationales…
Almost none.

…with the effect that post-mortems become impossible.
Yes.

Wrapping up

What do you plan to do now? Are you working on any other books?
I don’t plan to publish another book. I am putting together some memory essays for the benefit of the grandchildren, but I don’t plan to publish them. I have nine grandchildren, you know.

Congratulations!
Well, that’s not much of an achievement on my part [Laughter].