Review By: Brian Lawrence
05/15/2005More than twenty years ago I first heard of Fred Brooks’ The Mythical Man-Month. It was highly recommended to me by a colleague. But I didn't act on the recommendation until about seven years later, after a few "interesting" software projects, and more recommendations from colleagues. The book explained quite a bit about what had happened on all those projects, and in retrospect, I wish I had read the book sooner. On the other hand, maybe I wouldn't have recognized the significance of the book until I had more years of project experience.

For example, you might be familiar with Brooks Law, which was introduced to our industry on page 25: "Adding [staff] to a late project makes it later." I've seen this done several times. Managers add staff late, and then they're (surprisingly) surprised at the resulting lateness of the project. Everyone should be aware of this principle.

Another example I've seen is projects that fail to "plan to throw one away." The author’s idea is that the first software version will be incomplete and full of defects, so you're going to throw it away anyway, whether you planned to or not. So you might as well plan on it. This kind of thing occurs often in Internet development, and it is very common in other industry areas. In his recent comments, the author softens his stance a bit, focusing more on incremental or evolutionary development rather than "throwing one away." Instead, he suggests we focus on keeping in mind that significant changes may be needed to early software versions, and think about how we can be prepared to make those changes at the proper time.

I was intrigued when the 20th Anniversary Edition of this book was printed in 1995, which is when I purchased it. Even though most of the material is the same as in the original, it’s well worth the price. The author has added comments on how his thinking has changed, or how it hasn't, in the generation since the initial publication. He also added some new chapters, including a reprint of the classic, "No Silver Bullet: Essence and Accidents of Software Engineering," which appeared earlier in IEEE Computer.

One accusation I've heard leveled at this book is that it’s outdated—we know about this stuff because it’s been around forever. This is perfectly true. It’s also true that software managers routinely ignore the advice offered in this book, to their detriment. So maybe it isn't as outdated as we are inclined to think.

The author spends quite a few words discussing feedback from other people on his original work, which I found helpful in understanding different perspectives on the material. He also added some new reflections on the added "No Silver Bullet" article which he called "'No Silver Bullet' Refired." He stands up and then shoots down several critiques from colleagues on the existence of silver bullets of one kind or another.

The author finally concludes that the original premise still stands—there is no magic solution to the difficult problems of software development—and there never will be. You can take the message as encouraging us to keep trying new and innovative approaches to software development.

Looking back, I wish I'd read this book sooner. It may be "outdated" but it rings true. When it was originally published all those years ago, it redefined our thinking about software engineering. We can still learn some lessons from it. Don't wait as long as I did to read it.