What Was Still Is

Fred Brook's book, <i>The Mythical Man-Month</i>—published 25 years ago—remains relevant to software development and project management today.

• By Mike Gunderloy
• 05/01/2001

This month, I'm going to suggest a book that I think all software developers (and their managers) should read. It contains some of the latest thinking on what it takes to build great software.

It was published in 1975.

The book is The Mythical Man-Month, by Frederick P. Brooks, Jr. If you don't already own a copy, you should try to hunt down the Anniversary Edition, which includes new chapters and reflections from 1995.

Brooks wrote this book over 25 years ago, based on his experiences working on the software for some of the first IBM mainframes. Are the lessons from that project still relevant to software developers today? Yes! Here's why I think every developer should read or re-read (as I did this past week, despite having read it a dozen or more times in the past) this seminal work.

I got started programming computers the same year that the first edition of this book was published. It's easy to feel old and out-of-date after that time, and of course there are quaint passages that one can poke fun at. Let's get that out of the way first, shall we? Here's a sample this might look a bit dated. In discussing "crude, wasteful, and inelegant" software, Brooks mentions:

For example OS/360 devotes 26 bytes of the permanently resident date-turnover routine to the proper handling of December 31 on leap years (when it is Day 366). That might have been left to the operator.

The temptation is nearly overwhelming to read that and think, "Heh, those old-timers. Worried about 26 bytes! I'll bet they programmed with pointy sticks on clay tablets, too." It's easy to dismiss a concern over 26 bytes of memory as completely outdated and irrelevant.

And yet, and yet…
Even in these days of hundreds of megabytes of cheap memory, we still hear complaints of program bloat. And, I think, with good reason. Have you ever tried to run Microsoft Exchange and Microsoft SQL Server on the same machine and watched performance drop through the floor? Have you ever waited patiently (or not so patiently) for Windows to refresh the screen display of a complex Access form so you could get on with your work? Have you ever been involved in a dot-com programming project where bytes had to be shaved to keep the download size to something people would actually grab? Memory constraints aren't gone; they're just presented on a different scale than they were when OS/360 was designed.

Thinking about resource constraints and tradeoffs is one of the themes that runs throughout The Mythical Man-Month. Time vs. space, disk vs. tape vs. RAM (or "core"), deliverability vs. functionality, transparency vs. information hiding…it's quite clear that Brooks views a large part of the job of the software architect as that of making decisions and balancing things. He makes the point over and over that designing things well up front prevents nasty surprises and retrenching later on.

And if you think that's routine and obvious—why do you suppose most applications these days drop features long after the beta process starts? It's because developers as a group still make lousy estimates of what they can accomplish within fixed resource limits.

There are other lessons in this book as well. Brooks's Law, quoted at the start of this chapter, should not be news to anyone. When you're working on a complex project that falls behind schedule, adding more people can turn an inconvenience into a disaster, because the new people need to be trained and the load of communication within the project goes up exponentially. Most developers I talk to seem to understand this. So why do their managers up the head counts for struggling projects?

Brooks's other major contribution to thinking about software development is his essay "No Silver Bullet—Essence and Accident in Software Engineering" (included in the Anniversary Edition, not in the original book). To understand the argument in this essay, you need to understand the Aristotlean distinction between essence and accident as philosophical terms. As Brooks puts it:

By accident, I did not mean occurring by chance, nor misfortunate, but more nearly incidental, or appurtenant. I would not denigrate the accidental parts of software construction; instead I follow the English dramatist, detective story writer, and theologian Dorothy Sayers in seeing all creative activity to consist of (1) the formulation of the conceptual constructs, (2) implementation in real media, and (3) interactivity with other users in real uses. The part of software building I called essence is the mental crafting of the conceptual construct; the part I called accident is its implementation process.

Once you understand this somewhat technical distinction, you can understand the point of the essay: unless you think that accident accounts for 90% or more of the software development process, no new technique, innovation, tool, language, or framework can deliver an order-of-magnitude improvement in programming productivity.

Think about the last hard software project you tackled. How long did it take? How much of that time was spent in coming up with the design, figuring out what the user interface should look like and how it should work, considering boundary cases, specifying the behavior for erroneous input, coming up with test cases, and doing other design work? Was it less than 10 percent of the total time? It sure wasn't for me. I haven't measured lately, but my guess would be that design—including the little bits of mini-design, when I get stuck in the code and stare at a wall for ten minutes, thinking about the way out—account for 50 percent of my programming time.

Which means that even a miraculous software tool delivered by the Good Fairy that could suck the specifications out of my brain and implement them in error-free software would only cut my software development time in half.

Sure; sounds reasonable. Most developers that I know would agree that the hard, time-consuming part of their job is design—what Brooks calls essence. So, then, why do we continually fall for the siren song of the latest innovation, whether that be object-oriented programming or Microsoft.NET? Do you expect to be 90% more productive the first month you write .NET applications? How about the first year? How about over the entire time you use .NET before some new acronym displaces it?

I sure don't. I'll end up doing .NET development (hopefully only for applications where it actually makes sense), but I expect to spend more time, not less, on such applications, especially when I'm learning how to write them. If there's a benefit there, it will be in functionality, not in speed of development.

There are plenty more things in this book to provoke thought in the average developer. For example, Brooks thinks about how a programming team might be structured for rapid development, and comes up with a pilot-copilot metaphor that nicely foreshadows today's sexy technique of pair programming (part of "extreme programming," which I'll talk about one of these months). He also emphasizes the importance of good tools; if the essence of software is so irreducible, then we must do all we can to reduce the time we waste on the accident. I'll return to that theme in my column next month.

I think, though, that the most important lesson you can learn from this book is exemplified by the fact that the book exists at all: you can profitably think about the process of software design and development (thinking about thinking, or meta-thinking, if you like). When you're first learning to program, you need to immerse yourself in a morass of detail. It's not optional to get the variable declarations right, or to avoid off-by-one errors when writing loops. It's useful to understand stacks and linked lists and sort algorithms, and to know which one should be used when.

But that's not enough, not if you want to be a good software developer, or perhaps even a great one. Once you've mastered the basics, you need to start thinking about how to put them together into full applications. You need to think about what works and what doesn't, from design through testing to support. Even a simple technique like keeping a development log, or writing a post-mortem about what went right (or wrong!) with a project while it's still fresh in your mind, will help a lot with this process. And, of course, you can learn from others—which is why I'll close by recommending, once again, that you read this book.