Few books on software project management have been as influential and timeless as this one. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects.
These essays draw from his experience as project manager for the IBM System/360 computer family and then for OS/360, its massive software system. Now, twenty years after the initial publication of his book, Brooks has revisited his original ideas and added new thoughts and advice, both for readers already familiar with his work and for readers discovering it for the first time. The added chapters contain a crisp condensation of all the propositions asserted in the original book, including Brooks' central argument in The Mythical Man-Month.
Contains topics including:
Large programming projects suffer management problems different from small ones due to the division of labor
The conceptual integrity of the product is critical
It is difficult but possible to achieve this unity
Brooks' view of these propositions a generation later
A reprint of his classic 1986 paper "No Silver Bullet"
Today's thoughts on the 1986 assertion, "There will be no silver bullet within ten years."
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.