REVIEW: The Mythical Man Month: Essays on Software Engineering

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.

“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.” Rating 10/10

Jason Bennet
The Mythical Man Month: Essays on Software Engineering by Frederick P. Brooks, Jr. (Addison Wesley, ISBN 0-201-83595-9)

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, read below and enter into the wonderful world of software engineering.

Background

Before I launch 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 in 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-1960s. Brooks is trying to figure out what was done right, and what was not, especially in how the overall program was structured and managed. He thus sets out to write one of the first treatises on software project management, an indispensable 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 people’s 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 architecturally 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 facets 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 then we win.

More to the point, we as an industry must raise the 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.

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

Reference

Text written by Jason Bennet and extracted from here

Purchase the book over here at Amazon