The Mythical Man-Month is something of a legend among software-engineering books. It's spawned memes like "the second-system effect", "Brooks' Law" (Adding manpower to an already late project only makes it later), and the dread "Build one to throw away, you will anyhow". The 20th anniversary edition contains four additional chapters, written after the first book and with some new thoughts.

Brooks writes this book mostly from the perspective of a disappointed OS/360-project manager. As such, the book is mostly directed towards managers -- although programmers can benefit from it, a little. Brooks' main thesis seems to be:

the more people you have working independently, the more complex their communication must be. That communication is what drags down a software project into the morass of failure. Try to simplify the communication by:

• Keeping the project as simple as possible. (The second-system effect is, basically, trying to cram in as many features as possible.)
• Organizing programmers and staff into sub-teams that can work independently, connecting their components through well-defined interfaces. (Sound familiar? Brooks was preaching this dogma nearly thirty years ago.)
• Maintaining terse, up-to-date, and useful documentation so that people can more profitably RTFM.
• Separating architecture and design from implementation, and keeping the number of architects to a minimum, to ensure both a self-consistent design and a single authoritative designer.

Brooks also writes many good bits about scheduling (coding doesn't take as much time as you think; testing takes far more), division of expertise (good coders often make poor managers; don't "promote" them into management just to increase their seniority); schedule SNAFUs ("How does a software project become a year late? One day at a time."); and the like.

The thing that pissed me off the most about this book was the fact that Brooks has changed his mind in the intervening twenty years (he accepts data hiding, rather than rejecting it; and he no longer advises people to throw away their first hacks at a problem when most of the code is likely perfectly good) -- and he stuffs his diffs in the last few chapters, rather than re-writing. This may be chronologically honest, but it doesn't make for a terribly useful book. I pity da foo' who starts a big software project after making it only most of the way through TMM-M. While I praise Brooks for having the guts to write section titles like "Parnas was right, and I was wrong", I wish he'd taken the time to re-write the "wrong" bits instead of appending an erratum. (The other thing that pisses me off about the book is the author's use of end-notes, rather than footnotes. Grr.)

Programmers, especially programmers who work alone or in small groups on little projects, won't get much out of this book. What they get will probably be useful, but if you're going to buy a book to make you a better programmer, The Pragmatic Programmer is probably a better choice. Managers, on the other hand, should be required to read this book before they ever tell a programmer what to work on -- forced to read it at gunpoint, if need be.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.