All Book Reviews.

Book Reviews: The Mythical Man-Month by Frederick Brooks, Jr.

This book review was written by Frank Chance

Introduction

Published in 1975, The Mythical Man-Month is a classic text on software development. A 1995 edition includes several new chapters of interest, but the original essays remain the heart and soul of the book. In this book, Brooks tackles the question of how to organize and manage large-scale programming projects. These are projects that require hundreds or thousands of programmers, and result in millions of lines of code (think SAP, or Oracle’s database engine, or Windows 2000). The book is organized as a series of concise essays. In this review I’ll discuss the opening essay -- one of my favorites.

The Tar Pit

Brooks opens his first essay with a comparison between the tar pits of prehistory and large-system programming:

“In the minds’ eye one sees dinosaurs, mammoths, and sabertoothed tigers struggling against the grip of the tar. The fiercer the struggle, the more entangling the tar, and no beast is so strong or so skillful but that he ultimately sinks. Large-system programming has over the past decade been such a tar pit, and many great and powerful beasts have thrashed violently in it. Most have emerged with running systems--few have met goals, schedules, and budgets. Large and small, massive or wiry, team after team has become entangled in the tar. No one thing seems to cause the difficulty--any particular paw can be pulled away. But the accumulation of simultaneous and interacting factors brings slower and slower motion. Everyone seems to have been surprised by the stickiness of the problem, and it is hard to discern the nature of it.”

Remember, these words were written in 1975. Do they still apply today? Consider Windows NT 5.0. First scheduled to appear in 1997, it slipped to early 1998, to late 1998, then to 1999 (whence it was renamed Windows 2000). Here are some public estimates:

5,000 programmers.

35,000,000 lines of code.

Clearly, NT 5.0 qualifies as a large-system programming project. And just as clearly, Brooks’ tar pit is as prevalent today as in 1975!

Let’s carry on with the NT 5.0 example. Assume the worst case, that all 35,000,000 lines are new code. It’s reasonable to assume that the development started in roughly 1994. So we have:

5,000 programmers x 5 years = 25,000 programmer-years.

35,000,000 lines of code / 25,000 programmer-years = 1,400 lines per programmer-year.

If you are a programmer, or have ever taken a programming class, this number (1,400 lines per year) seems amazingly low. Most of us have hacked together a bit of code that approaches one thousand lines in just a day or two. How could it possibly take a Microsoft programmer an entire year to complete 1,400 lines?

Two possibilities spring to mind:

Microsoft hired 5,000 incompetent programmers to develop NT 5.0.

OR

It’s a lot harder to write a large-scale programming systems product than to hack together a single program.

Brooks would argue that the latter answer is the correct one. He starts by defining terms:

(1) A program

An individual program is the result of our two-day programming binge. It is ready to run by itself, on the machine where we wrote the code. If we add documentation, generalize the code, write test cases, and make the code maintainable by a general programming audience, we have:

(2) A programming product

Alternatively, if we take our program and completely define its interfaces according to a predefined specification, and test its interaction with a large number of other components, we have:

(3) A programming system component

And if we do both (add documentation, generalize the code, write test cases, make the code maintainable, define its interface, test its interactions), we have:

(4) A programming systems product component

Brooks uses a 3x rule of thumb for the work required in taking each of these steps:

(2) = 3 times the effort of (1)
(3) = 3 times the effort of (1)
(4) = 9 times the effort of (1)

Or, in words, development of a standalone program requires only 1/9th the effort required to develop a component in a programming system.

Returning to our Microsoft example, if we apply this 9x factor to the 1,400 lines per programmer-year productivity measurement, we get 12,600 lines per programmer-year (e.g. if we took each of those programmers and set them to work in isolation, hacking away on a single program). In a separate essay, Brooks quotes a manager who found that, on average, his programmers only spent half of their time developing -- the rest was consumed by paperwork, meetings, and various other tasks. Factoring this into the Microsoft example, we arrive at 25,200 lines per programmer-year. And the Microsoft programmers begin to look more respectable.

In another measure of just how little has changed since 1975, Brooks quotes an estimate of 1,000 lines per programmer-year. If the 1,400 lines per programmer-year quoted above is accurate, it represents a productivity gain of just 1.75% per year for the 20 years between 1975 and 1995. This result confirms another of Brooks’ hypotheses -- that productivity of programmers is relatively constant, no matter the language used for development. Therefore, the real productivity gain comes from moving to a higher-level language, where each line represents more actual work.

Although aimed at large-system projects, Brooks’ commentary often applies more generally. For example, this first essay closes with sections titled “The Joys of the Craft” and “The Woes of the Craft”. Under woes, he discusses the problem of obsolescence:

“... the product over which one has labored so long appears to be obsolete upon (or before) completion. Already colleagues and competitors are in hot pursuit of new and better ideas. Already the displacement of one’s thought-child is not only conceived, but scheduled. This always seems worse than it really is. The new and better is generally not available when one completes his own; it is only talked about. It, too, will require months of development. The real tiger is never a match for the paper one, unless actual use is wanted. Then the virtues of reality have a satisfaction all their own.”

Summary

Brooks’ essays cover a variety of the challenges inherent to large-system programming, but are useful reading for anyone involved in software development. The name-sake essay (The Mythical Man-Month) discusses the indivisibility of many programming tasks, and why this makes the addition of manpower to a software project a futile effort. My other favorites are “Aristocracy, Democracy, and System Design” (a discussion of conceptual integrity) and “Plan to Throw One Away” (on the benefits of explicitly planning for multiple releases before shipment). Some questions have been made obsolete by technological advances, for example the discussion of how to distribute type-written documentation among a large team. You will be surprised, however, at how many of the problems that Brooks faced still frustrate us today. As an added benefit, the brevity and clarity of Brooks’ writing make it a delightful read. If you are a programmer, if you work with programmers, or if you manage programmers, you should read this book.

References

If you would like to buy this book, just click on the following link to open a new window and go directly to The Mythical Man-Month on Amazon’s website. FabTime is an Amazon affiliate.

For a quite different view of systems development, see The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, by Eric Raymond, also available from Amazon. In the spirit of open-source development, you can also download “The Cathedral and the Bazaar” from  http://www.tuxedo.org/~esr/writings/cathedral-bazaar.