Code Reads #1: The Mythical Man-Month

This is the inaugural edition of Code Reads, a weekly discussion of some of the central essays, documents and texts in the history of software. This week we’re talking about Frederick Brooks’s The Mythical Man-Month. (OK, let’s be honest: I’m talking about it. I’m hoping you, or you, or you, may want to, as well! If you don’t want to read my essay, you can just go straight to the comments and post something.)

Frederick Brooks’s The Mythical Man-Month came out in 1975, and I first heard its title later that decade. I’d already been a teenage programmer of sorts (of games in BASIC) for a few years, but I knew nothing of the world of large software projects that Brooks’ work addressed. I did know that the phrase “mythical man-month” grabbed my interest. It sounded less like the management-science term it was, more like a description of some prehistoric beast, heaving itself out of the primordial swamp to lumber across a desolate landscape.

Transmuting dry corporate-speak into evocative imagery? That was some trick.

When I finally did read Brooks’s book, more than two decades later, there, on its cover, were those beasts — struggling to pull their limbs free of the tar pit that served as Brooks’s starting metaphor for the awful dilemmas of software-project scheduling. By that time, I’d become more familiar with the sort of work Brooks’s book addressed. I’d knocked my head more than once against the wall of software development. And I found, as so many readers had before me, that this quarter-century old book anticipated and analyzed most of the problems I’d encountered — and even offered some useful advice on how to avoid them.

The Mythical Man-Month is best known for its formulation of Brooks’s Law: “Adding manpower to a late software project makes it later.” Software development isn’t like harvesting corn or carving widgets; since each project’s work is unique, when newcomers join up, the existing experts need to drop what they’re doing and orient the new recruits. And as the project’s roster grows, so too does the amount of time each participant has to devote to coordinating his work with a greater number of colleagues.

Brooks’s Law is so counter-intuitive that one still regularly encounters projects that ignore it, on the assumption that either (a) their particular undertaking is uniquely exempt from Brooksian limits or (b) the project employs some new methodology that invalidates Brooks’s principle. (One central argument of Eric Raymond’s “The Cathedral and the Bazaar” is that open-source methods combined with an efficient communications network like the Internet can overcome the logic of Brooks’s Law and allow the efficient deployment of swarms of developers in debugging efforts.)

But much more than Brooks’s Law awaits those developers who wish to go beyond the catchphrase level of familiarity with The Mythical Man-Month. The book introduces a whole slew of concepts at the heart of our understanding of how we build software:

• How do disastrously late projects get that way? “One day at a time.” (Brooks applied this phrase to the software field long before it became a 12-step self-help mantra.) Most slippage is the offspring of “termites, not tornados.”
• Sequential constraints: Some projects take an irreducible amount of time because one part of the task needs to be finished before the next can be begun — or, as Brooks puts it, “The bearing of a child takes nine months, no matter how many women are assigned.”
• Coding isn’t what takes the most time: Brooks’s rule of thumb is that actually writing the code takes 1/6 of a project’s time — with planning taking another third and the remaining half devoted to testing and debugging.
• Programmers vary wildly in individual productivity: Wildly as in the highly productive programmer may well be able to produce ten times more useful stuff, however you choose to measure it, than his colleague.
• The goal of “conceptual integrity” or unity of design: The best programs and software systems exhibit a sense of consistency and elegance, as if they are shaped by a single creative mind, even when they are in fact the product of many. The fiendish problem is less how to create that sense in the first place than in how to preserve it against all the other pressures that come to bear throughout the process of writing software.
• The “second system effect”: Brooks noted that an engineer or team will often make all the compromises necessary to ship their first product, then founder on the second. Throughout project number one, they stored up pet features and extras that they couldn’t squeeze into the original product, and told themselves, “We’ll do it right next time.” This “second system” is “the most dangerous a man ever designs.”

Brooks’s success in The Mythical Man-Month at defining the nature of the software-project beast depends, I think, on to two special characteristics of the work: its roots in Brooks’s personal story, and the power and clarity of its style.

The Mythical Man-Month traced its origins to Brooks’s experiences leading the team tasked with writing the IBM 360’s operating system — an unprecedently huge project that suffered legendary delays . At a 2004 event the Computer History Museum held marking the 40th anniversary of the birth of the IBM/360 project, Brooks recalled the book’s genesis:

When I was leaving IBM, Tom Watson Jr. and I had a very good conversation. He said, “You’ve managed the hardware part of the project, and you’ve managed the software part of the project. What is the difference, from a management point of view, between the hardware and the software? Why does software seem to be so much harder to manage?”

And I said, “Well, I can’t answer that on the spot, but I’ll think about it.” And it took five years.

I think it’s important, in reporting a development effort, to indicate what you tried that didn’t work as well as what you tried that did work. And the fact that I’d consider the OS/360 effort phenomenally successful doesn’t meant that I think that everything we did along the way was wise. We made some stupid blunders.

There’s an urgency to The Mythical Man-Month that makes it more immediate, and more satisfying, than most run-of-the-mill business books. Brooks emerged from the IBM project asking passionately, “Where did we screw up?” — and trying to record the answers for the benefit of futures toilers in code.

None of that would get Brooks very far, or have us reading him three decades later in this volatile field, without his unusual skill at expressing complex ideas: He is at once forthright and graceful. He draws just enough parallels from outside the field (a New Orleans restaurant menu, the Tower of Babel) to leaven the proceedings without ever sounding gimmicky. Even when he’s packing multiple polysyllables, his sentences flow with power:

Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.

And at times his eloquence waxes positively Elizabethan:

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination.

Is The Mythical Man-Month dated? Some of it, sure. At one point, Brooks says, “I am convinced that interactive systems will never displace batch systems for many applications.” Oops. (Brooks graciously cops to this and some other mis-predictions in his retrospective postscript, “The Mythical Man-Month After 20 Years.”) Still, even such a cloudy-crystal-ball passage has some value today: it made me wonder about the times I’ve said, echoing other computer users of my generation, “I can’t ever see Web-based software entirely replacing desktop applications.” Such certainties could well prove as fleeting as Brooks’s confidence in batch mode.

The Mythical Man-Month also devotes many pages to discussions of the proper management of the five-foot-thick “project workbooks” of a bygone era. In the days before intranets and wikis and source-code repositories, these were the tools a team used to coordinate work. No one will shed a tear for the demise of fat binders. But today’s wheel-reinventers could probably benefit from an examination of how previous generations got their teams rolling in sync.

In other words, even in those passages where it’s showing its age, The Mythical Man-Month remains valuable. It’s a remarkably enduring work. It was the first book I turned to when I began my quest to understand why software is so hard, and I know I’ll keep returning to it. Anyone trying to create software is, as Brooks paints the picture, traversing a pit; The Mythical Man-Month offers us “boardwalks across the tar.”