The Independent Magazine for
Software Development Professionals
Two Ways to Keep Up
1. Newsletter
Our newsletter policy:
No list sharing of any kind.
No "special offers" from "partners."
No "webinars." No "Special Reports."
No junk.
2. RSS Feed
Are you missing out on RSS?
Click to learn more.



Add to Your Reader:
Search Now:
VBScript Programmer's Reference
Discover the full power of VBScript. Windows Script Host, ASP, ADO, Microsoft Script Control, error handling and debugging, regular expressions, classes, FileSystemObject, Dictionary, script encoding, script components, and more.
All content copyright 2000-2006 by the individual specified authors (and where not specified, copyright by Daniel Read). Reprint or redistribute only with written permission from the author and/or developer.*.
A Classic in the Field, Updated & Expanded
Foreword by Andrew Hunt
Nearly 60 Essays by a Software Pioneer!
“One of software's most versatile and creative writers.”
20% Off the Cover Price in the US!
More Ordering Options
Book Review

The Mythical Man-Month: Essays on Software Engineering (20th Anniversary Edition)

By Frederick P. Brooks, Jr. (Review by Daniel Read)

Addison-Wesley, 1995, 322 pages (ISBN 0201835959)
Posted November 13, 2002

If a book about software development has sold over 250,000 copies (almost unheard of for technical books) and after 28 years is still in print, and selling well, it's a pretty good bet that it has something significant to offer. Indeed, Frederick Brooks's The Mythical Man-Month has much to offer today's software practitioner, not to mention today's software manager. Reading the book 28 years after its initial publication, it becomes apparent that the software development challenges the book describes are still as much--or more--of a challenge today as they were when these words were first written, and that the Brooks's conclusions and advice have, for the most part, withstood the test of time equally well.

The essays in The Mythical Man-Month cover a variety of topics, from management-related topics such as estimating and process, to lower level design and construction topics. The best essays in the collection, however, are those that deal with the higher level topics like people; process; scheduling and estimation; architecture and the conceptual integrity of systems; the nature of software development; and the state of the discipline and field. These essays are also the ones that have aged best. (Unfortunately, the more purely technical essays, such as "Sharp Tools," have not fared so well, but these make up only a small part of the book.)

To a working developer, it may not seem like such theory-oriented topics would be of much interest. However, as a working developer myself (though, admittedly, I don't get to write as much code these days as I'd like), I read these essays with great interest.

In my opinion, the best developers are not those who have skills for coding novel and elegant solutions to difficult technical challenges (though of course that's important), rather the best developers are those who also have a wider view of software development than just the code in front of them. That is why you will find that many of the books reviewed on the developer.* site are not purely technical books. In the high-pressure worlds of software development for business and government, the biggest challenges to building great software are not technical challenges.

Of course, bad programmers writing bad code can doom a project, but haven't we all seen projects filled with bad designs and bad code "succeed" by going into production and living long lives? More often, project failures are caused by things such as faulty or missing requirements, unreasonable schedules, project management mistakes, staffing errors, politics, and poor choices of technology/platform. (Another good book, Software Runaways by Robert Glass, is a good confirmation of that statement.) Even if in your current job function you do not have control over such things as requirements, scheduling, and staffing, you are still directly affected by these realities, and a deeper understanding of their dynamics is beneficial for at least three reasons:

  • An understanding of larger, non-technical issues can give you a strategic view to complement the tactical view so essential to design and construction job functions.
  • If you aspire to become involved in software development projects at a higher level in a role such as technical lead, architect, or project manager, then understanding of the less technical subjects is essential.
  • At the very least, it's good to know how to read the signs of the classic problems described in The Mythical Man-Month so that you will not be caught unawares on a failing project.

Besides these benefits, there is a lot of fun to be had because, inevitably, you will laugh knowingly as you remember a past project (or your current one) that has fallen into the exact pitfalls Brooks describes.

All of the preceding is a long-winded way of saying this: The Mythical Man-Month is a classic work that you would likely enjoy reading even if you don't normally pick up this type of book. Brooks never bogs down into the boring mechanics of the aforementioned subjects. Rather, he keeps the discussion focused on the more universal aspects, which makes the essays easy to relate to and the reading quick.

My favorite essays of the collection are at the beginning of the book. "The Tar Pit" is short, but does a nice job describing what makes software development both difficult as hell and fun as hell. The title essay alone will convince the casual reader why this book has endured. Anyone who has ever had to face the questions: "When can you have it done?", "What is the status?", and "Why isn't it done yet?" will feel better reading it. This is a great passage (especially the first sentence):

"Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelette, promised in two minute, may appear to be appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices--wait or eat it raw. Software customers have had the same choices.

"The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save--burned in one part, raw in another." (p 21)

Perhaps my favorite essay, though, is "Aristocracy, Democracy, and System Design." In this essay, Brooks argues for the importance of the "conceptual integrity" of systems, meaning that the best systems have a unified consistency about them, making them easier to understand, use, and maintain. Brooks asserts that this can only be achieved if the entire system design is overseen by no more than one or two people, even if there are many more people than that participating in the design and construction. He writes,

"I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, then to have one that contains many good but independent and uncoordinated ideas. … Simplicity and straightforwardness proceed from conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata. Every part must even use the same techniques in syntax and analogous notions in semantics. Ease of use, then, dictates unity of design, conceptual integrity." (pp 42, 44)

This anniversary edition also contains four additional chapters from the original edition. One of the chapters is the controversial and widely read essay "No Silver Bullet--Essence and Accident in Software Engineering." This very enjoyable and highly readable essay provides great insight into the nature of software development, specifically, what makes it so challenging, and why attempts to invent a "silver bullet" that will solves those changes are doomed to fail.

The book wraps up with "The Mythical Man-Month after 20 Years," written in 1995, when this edition was published. I very much enjoyed this, as it reexamines many of the topics and conclusions of the original essays in light of the intervening time. Brooks is humble about conceding where he was wrong, and also quotes and responds to the other people's responses to the essays. The essay closes with this:

"This complex craft will demand our continual development of the discipline, our learning to compose in larger units, our best use of new tools, our best adaptation of proven engineering management methods, liberal application of common sense, and a God-given humility to recognize our fallibility and limitations." (p 289)

If you have some time in your reading schedule, The Mythical Man-Month is definitely worthy of that time.

Related Information

Daniel Read is editor and publisher of the developer.* web magazine. He lives in Atlanta, GA, where he works as a software architect and programmer. He is currently at work on about a million different things.