http://qs1969.pair.com?node_id=22507
Order The Mythical Man-Month

Item Description:

Review Synopsis:

The Mythical Man-Month by Frederick P. Brooks
ISBN 0-201-83595-9
Copyright 1995, Addison-Wesley

Capsule Review

Excellent book. 5 stars out of 5.

Who should be interested in this book?

Full Review

It may surprise many to learn that a book about the computer industry written in 1975 is still relevant today. But it is painfully relevant. Painful because, as you read Fred Brooks' book, you'll likely see your company in his words, and you'll see that your management still hasn't learned what Fred Brooks was teaching 25 years ago. Of course, depending on your attitude, maybe you won't find any of this book to be painful. Maybe you'll feel vindicated for saying what you did in that meeting three months ago that pissed your manager off so.

The strength of this book is that it takes all the stray thoughts, irritations, frustrations, and observations you've ever had while working on a large project, and congeals them into simple, straightforward ideas. Paraphrasing one such idea:

If you're working on a project where a lot of communication is required, the amount of time spent in meetings increases exponentially with the number of people on the project. So, you should try to break the project up into autonomous units, or keep the number of people on the project to a minimum so they have time to get real work done. Simple, right? And he even puts in graphs so your manager can understand it.

Brooks also makes some suggestions that, while they make good sense, nobody seems to have taken seriously. One example is his "Surgical Team". We've all worked in teams where there was a good division of responsibility, but not to the degree Brooks suggests. In his version, there's only one person, the "surgeon," who does the vast majority of the coding. Another person is sort of an understudy whose primary purpose is to review all of that person's code and serve as a sounding board and devil's advocate for the surgeon. Somebody else is responsible for unit testing everything the surgeon produces. And then there are other supporting roles that I won't go into here. A fascinating concept, and one that would no doubt produce excellent quality. But it just looks too expensive for anybody to actually do it.

Of course, the classic unused suggestion -- probably the one thing everybody has heard from this book -- "Plan to throw the first one away, because you will anyway."

In summary, an excellent book on the problems and pitfalls of developing new systems.

*Woof*

Replies are listed 'Best First'.
RE: The Mythical Man-Month
by Dogg (Scribe) on Sep 27, 2000 at 01:32 UTC
    As much as I hate to praise anyone at the University of North Carolina at Chapel Hill, this is really an interesting and valuable book.
    Above, splinky highlights some of the main points contained in the book. I completely agree with him regarding the overall quality and value of the book and just wanted to add a few comments from a differentperspective.

    I got my hands on the 20th Anniversary Edition of The MM-M which includes 4 new chapters. As noted above, the quality and continuing relevance of the author's original writings/ideas (in 1975) is impressive. The new chapeters, added in 1995, are devoted to reexamination of those ideas, updating his theories, and debating certain criticisms of his original book.

    I am not a software engineer and I do not make my living writing computer programs. I have never seen the IBM System/360 that serves as an example for so many of the author's theories and experiences. Despite all that, I still found a lot of valuable ideas in this book (really a short collection of essays). And Brooks himself notes that a significant amount of correspondence regarding the original work has come from outside the field of computer science/software engineering. Most of the more general ideas apply to anyone managing people or complex systems.
(jeffa) Re: The Mythical Man-Month
by jeffa (Bishop) on Mar 28, 2001 at 02:31 UTC
    Reading about 'Surgical Teams,' I suddenly remembered that my compiler professor used this method, round robin style.

    eduardo coded the first phase, I did the documentation and played devil's advocate, and our buddy Nathan did unit testing.

    Next phase, everybody shifted, likewise for the third and final phase, which I had to code.

    I found it to be a very rewarding strategy, even though it was only an acedemic effort.

    Jeff

    R-R-R--R-R-R--R-R-R--R-R-R--R-R-R--
    L-L--L-L--L-L--L-L--L-L--L-L--L-L--