|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.
|Review by: Jason Bennett|
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.
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:
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 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.
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.
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.
In 1991, future coverstar Linus Torvalds released a little kernel which has ended up working in synchrony with GNU utilities and
software projects to live happily on millions of computers worldwide. Read about the beginnings of the Linux kernel peppered with
anecdotes about growing up Finnish, straight from the horse's mouth, with Linus's book Just For Fun,
coauthored by David Diamond. This makes a lighthearted companion piece to the slighly-more-serious effort from
Pekka Himanen, The Hacker Ethic. |
And for your more serious moments, we've run reviews lately of the sobering Hack Attacks Revealed and the very informative Digital Copyright by noted authority in the field Jessica Litman. There's also the hard-to-categorize work from Ian Stewart called Flatterland, a modern update to the classic Flatland.
Visit Our Book Reviews Section for more.
|This discussion has been archived. No new comments can be posted.|
|Review: The Mythical Man Month: Essays on Software Engineering | Login/Create an Account | Top | Search Discussion|
|The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.|
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 SourceForge, Inc.