|Just another Perl shrine|
The Mythical Man-Monthby splinky (Hermit)
|on Jul 14, 2000 at 08:55 UTC||Need Help??|
Order The Mythical Man-Month
Excellent book. 5 stars out of 5.
Who should be interested in this book?
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.