Review: The Mythical Man Month: Essays on Software Engineering

A review of the venerable The Mythical Man-Month was sent our way by Jason Bennett. While this book has some years on it, the fact that it is still around is a testament to the strength of the text. This latest addition contains additional essays and thoughts about engineering. So, click below and enter into the wonderful world of software engineering.

The Mythical Man Month: Essays on Software Engineering - Anniversary Edition
author	Frederick P. Brooks, Jr.
pages
publisher	Addison Wesley Publishing Company, Inc.
rating	10/10
reviewer	Jason Bennett
ISBN	0-201-83595-9
summary

As a classic software engineering text, this book is only helped by the addition of Brooks' latest essays and reflections on his original conclusions. Remember, it won't do you any good unless you read it.

Background

Before I lauch into my review of The Mythical Man Month, I would be negligent if I did not explain the meaning of the first edition of this book. It's 1975. Programmers slave over some of the earliest dumb terminals on massive mainframes from the Great Monopolistic Satan of computing, IBM. Maybe, if their lucky, the programmers can work on a minicomputer from that upstart company, DEC, and their PDP series of computers. FORTRAN and COBOL are your staples, with some PL/I thrown in for good measure. C is a blip on the horizon, just starting to make its way out of Bell Labs. Assembly language is still widely used throughout the industry. Enter Frederick Brooks, one of the industry's originals. Brooks is reflecting on his time at IBM, specifically his working on the System/360 and its operating system, OS/360 (unique names, no?) during the mid-1960's. Brooks is trying to figure out what was done right, and what was not, especially in how the overall progam was structured and managed. He thus sets out to write one of the first treatises on software project management, an indispensible part of software engineering. Twenty-five years later, we are still reading the book and learning from it. In an industry where most books are useless after six months, this book is almost prehistoric. Remember, though, what level a book must reach to last so long.

What's Good?

You might be wondering why this book has lasted so long. The answer is simple: the technology of the book is secondary to the people lessons. Simply put, Brooks' points are the following:

1. Programming must turn into software engineering in order to continue to improve the state of the art.
2. Any well-engineered product must be conceptually and architectually whole.
3. The tar pit of software development can only be escaped through a conscientious, dedicated process.

There are so many classic lines in this book that a simple review cannot account for them all. The most famous, of course, is Brooks' Law of adding people to a late project (hint: it doesn't help). Surgical development teams, the second-system effect, and the importance of documentation are all covered, sometimes for the first time, in MMM. Through the course of the book, Brooks covers all fascets of what must happen to successfully complete a major software project, and in all parts he gives a firm foundation for solid software engineering and project management. In fact, this was the first major book to accurately assemble the knowledge needed to engineer a large software project into one place, and relate it from the perspective of a finished project.

In addition to the original chapters, Brooks' essay from 1986, No Silver Bullet, is included, along with Brooks' thoughts on his book twenty-five years later. These essays alone are worth reading, as they give an accurate estimate of where the industry is now. Suffice to say, the easy part is behind us. It's real work from here on in.

What's Bad?

What's bad about this book is that people don't read it. There's no particularly good reason, they just are too busy reading the latest book on today's fad. The irony, of course, is that today's fad will be laughed at next year, while MMM will still be around a decade from now. If you were assigned this book in school, read it again (you probably didn't the first time :-). If you've never heard of it, read it tomorrow.

What's In It For Us?

Why should any of us read this book? What does project management matter to a bunch of semi-organized groups? Aren't we doing fine as it is in our striving for World Domination? Well, yes and no.

On one hand, we don't have the pressures of commercial software. If Apache comes out tomorrow instead of today, no matter. Everyone else is just as bad, so we just have to not be worse. For that matter, most open-source projects are blessed with one or a few leaders who keep everything on track and in one vision. We don't have too many projects with lots of different architects.

On the other hand, we've been blessed with low expectations. No one expected us to succeed, so any measure of success was a victory for the movement. Now, all eyes are on us. If a release comes out a month late, everyone will think we're no better at keeping a schedule than Microsoft. If we have to rewrite another application because we did a poor design job, we aren't offering a valid alternative. We have to be better than everyone else to prove ourselves, and we cannot do that in an individually-oriented environment. If the open-source community can learn the lessons of MMM better than the rest of the industry, than we win.

More to the point, we as an industry must raise our expectations of our software. We need to strive for accurate schedules. We need to avoid the second-system effect. We need to understand why you cannot just add people to a late project to speed it up. In short, we need to care about producing quality software on time, instead of just getting stuff out there.

More to Come

This is the first in what I hope will be a series of reviews of software engineering book. My current company is trying to move to CMM level 2, and as part of that our Process Group is reading a series of books. Some of them are business or interpersonal oriented, but some others (like MMM) are software related. Hopefully, I'll kick out a review a week.

The net effect of this, I hope, is to get the open-source community interested in producing a complete, quality product instead of just neat functionality. In order for a program and project to last in the spotlight, it must have solid underpinnings. Only through applying the principles of software engineering can open-source projects fully achieve greatness.

Purchase the book over here at Amazon.

• Table of Contents

• Preface to the 20th Anniversary Edition
• Preface to the First Edition
  1. The Tar Pit
  2. The Mythical Man-Month
  3. The Surgical Team
  4. Aristocracy, Democracy, and System Design
  5. The Second-System Effect
  6. Passing the Word
  7. Why Did the Tower of Babel Fail?
  8. Calling the Shot
  9. Ten Pounds in a Five-Pound Sack
  10. The Documentary Hypothesis
  11. Plan to Throw One Away
  12. Sharp Tools
  13. The Whole and the Parts
  14. Hatching a Cataastrophe
  15. The Other Face
  16. No Silver Bullet - Essence and Accident
  17. "No Silver Bullet" Refired
  18. Propositions of The Mythical Man-Month: True of False?
  19. The Mythical Man-Month after 20 Years
• Epilogue
• Notes and References
• Index