Customer Reviews

The Mythical Man-Month: Essays on Software Engineering

5 star:		(4)
4 star:		(1)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

There really are very few software engineering books written in 1975 that are worth reading today. Brooks remains powerful stuff because large system projects are still often disastrous. We are not often bothered by the flowcharts that Brooks dislikes, but the disorganized projects, endless meetings, problems of scaling, unhelpful documentation and inflexible systems are certainly still with us.

I was struck recently by the parallels with Kent Beck's Extreme Programming: Brooks had in his way foreseen much of what this recent movement has been urging.

Brooks' classic book underlies much systems engineering thinking, and his example along with the frightening story of OS/360, enlivened with Brooks' inimitable anecdotes and illustrations, remains essential reading.

This is a classic tale of managment philosophy and software engineering. It contains some of the best descriptions of human behavior and engineering intuition ever distilled into book format. A must read for anyone managing, or working on, complex projects of any sort.

I learned by my own mistakes the meaning of the expression, "You can pay me now or pay me later." There are few or sometimes no short-cuts in software or hardware development or engineering, or electronics in general. Fred Brooks, best known as the "father of the IBM System 360," and after 30 years still holds the title of the most influential book on software project management, likened it to pregnancy. He said you can add all the women you want "to the project" and still, it will take nine months! That's why, in managing software development projects, I learned to spend ample time with the software developers beforehand. Otherwise, I would inevitably spend the time with them afterwards. I was the one knowing the design. I had the "big picture" that needed to be communicated to them.

In his book, Brooks described the foibles of the early design teams and programming at IBM. From his own mistakes, he came up with snappy principles like "If you don't have time to do it right the first time, when will you find time to do it over?" He also coined what became known as the "Second-System Approach," which basically said "by the time you finish developing a system, you know what you should have done"--therefore, throw it away and start from scratch again. He identified the corruptible optimism of good intentions that truly but erroneously believed, for most of the project, that the work was 90% done or that debugging was 99% done most of the time. He insisted, "Ask whenever there's a doubt. NEVER assume anything."

This book is filled with timeless development advice by a master from a previous age. The advice, however, is as valuable now as it was then.

A good, undying, informative, inspiring and enjoyable read!

Although much of the approach Brooks advocates has been common practice in the software industry in the 30 years since the book's publication, The Mythical Man-Month remains as relevant today as when it was written. It references obsolete platforms like System/360 and Multics, and is set in a world where punch cards and PL/I were state-of-the-art, but human nature hasn't changed. The few parts that are truly irrelevant remain charming, like this comment: "The Apostle Peter said of new Gentile converts and the Jewish law, 'Why lay a load on their backs which neither our ancestors nor we ourselves were able to carry?' I would say the same about new programmers and the obsolete practice of flow charting."

This book ought to be assigned in every introductory programming course, so students will better understand why they're being asked to create modularized, self-documenting code. The burden of the extra reading will be offset by their relief at not being required to flow chart their programs!

Written in 1974, this book has aged well and in many areas not at all. Which is both a good thing and a bad thing. It is good in the sense that Brooks identified many characteristics of software development at a time when software engineering was still a newborn. The bad part is that so many in positions of responsibility need to be reminded of the basic, and accurate, points in the book.
Creating software is like dieting, in that shedding the first few pounds is easy and can be done almost overnight. However, extrapolating from the initial results is foolish, as removing each pound after that gets harder and harder. And yet, many managers do not think that way. When initial results come back, they are positive and if extrapolated, lead to rosy conclusions. Managers, being a bit rosy in all four cheeks, tend to follow this, even though Brooks and all experience emphatically tell us that each additional step gets increasingly harder.
Many years ago, when the company I worked for hired a new CEO, the software developers recommended that he read this book. He did, but it didn't help. His attitude was that our situation was different, which it wasn't. The completely predictable result was that nearly every developer left in search of more realistic grazing grounds. If you are a manager of software development at any level, do everyone, including yourself a favor. Read this book and take it seriously, it will be one of the best ROI events you have ever had.