The Mythical Man-Month: A Review

I picked up Frederick P. Brooks Jr.'s The Mythical Man-Month from the library on the advice of my friend Judson, who called it "required reading for anyone in the software profession." I'm so glad I did! This is easily my favorite piece of writing about computer engineering.

(Note: All my page numbers come from the 20th anniversary edition, linked above.)

In the very first chapter, "The Tar Pit," Brooks gives a compelling list of reasons why programming is rewarding. He concludes it with:

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. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (As we shall see later, this very tractability has its own problems.) (p. 7)

Brooks writes clearly, intelligently, and occasionally very beautifully about the craft of software development. Another example of his wisdom wrapped in elegant prose comes later in the same chapter:

For the human makers of things, the incompleteness and inconsistencies of our ideas become clear only during implementation. Thus it is that writing, experimentation, "working out" are essential disciplines for the theoretician (p. 15). 

Although it has some lovely passages, the book is not principally a collection of creative essays about programming. Rather, it is Brooks's attempt to identify and correct some of the common problems that software development professionals go through. It contains some really good advice and valuable cautionary statements. For example, in the chapter that gives the book its title:

Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable (p. 16, emphasis in original).

This is excellent advice for programmers, but even better advice for project managers and upper management in technology companies. Brooks has valuable ideas, too, for technical writers:

English, or any other human language, is not naturally a precision instrument for [definitions of system architecture]. Therefore the manual writer must strain himself and his language to achieve the precision needed. An attractive alternative is to use a formal notation for such definitions (p. 63).

And again, for testers:

The project manager's best friend is his daily adversary, the independent product-testing organization. This group checks machines and programs against specifications and serves as a devil's advocate, pinpointing every conceivable defect and discrepancy. Every development organization needs such an independent auditing group to keep it honest. 

In the last analysis the customer is the independent auditor. In the merciless light of real use, every flaw will show. The product-testing group then is the surrogate customer, specialized for finding flaws. Time after time, the careful product tester will find places where the word didn't get passed, where the design decisions were not properly understood or accurately implemented. For this reason such a testing group is a necessary link in the chain by which the design word is passed, a link that needs to operate early and simultaneously with design (p. 69).

Some of the documentation sections also have important thoughts for UX designers:

A computer program is a message from a man to a machine. The rigidly marshaled syntax and the scrupulous definitions all exist to make intention clear to the dumb engine.

But a written program has another face, that which tells its story to the human user. For even the most private of programs, some such communication is necessary; memory will fail the author-user, and he will require refreshing on the details of his handiwork.

I really love Brooks's concrete examples. To illustrate the role of upstream dependencies in planning, he writes that "The bearing of a child takes nine months, no matter how many women are assigned" (p. 17). Later, he gives the extended example of an omelette when discussing why it's important not to deliver a product before it's ready (p. 21).

For all of its usefulness, this isn't a perfect book. It was written in 1975, so many examples and ideas are outdated or irrelevant.

For instance, we don't need a pool of typists to compile the code changes from the previous day and bind them in a book for distribution to all programmers. Shared version control has thankfully made that practice a thing of the past.

There are also lengthy treatments of sharing processing time, dumping memory to printouts for debugging, and low-level hardware and software concerns that modern programmers simply don't have to deal with anymore.

For this reason, some reviewers have complained that the book is so outdated as to be of very little use. I have a couple of responses to this:

1. Many of the technological advances we enjoy today are owing to people like Brooks, who highlighted the difficulty of the status quo. This book is such a fundamental building block in our field that it has almost certainly encouraged the growth of IDEs with integrated debuggers, shared source control repositories, and so on.
2. Even though some parts are not relevant today, they still serve a valuable historical purpose. In addition, they often have analogs to problems we face in programming today.

Another drawback that some reviewers have noted is Brooks's very traditional mindset. For example, he makes no effort to consider the existence of women in any role other than members of the secretarial pool. The theoretical programmer always gets "he/him/his" pronouns. While this is problematic in our modern culture, it is perhaps relevant that in Brooks's time, very few women were programmers. Thus, his assumption that they would be male is at least statistically defensible, if not ideologically so.

I think this book is worth a read for anyone in the software development industry. Project managers and people managers would find it especially useful, I think. Most of the less useful and applicable portions are later in the book, so I'd advise reading the first three or four chapters pretty carefully, then skimming the remainder if you'd prefer.