|The World According to Nick|
|My take on Software, Technology, Politics, and anything else I feel like talking about.|
Saturday, June 19, 2004
The Mythical Man Month by Frederick P. Brooks
I picked up this book last weekend because it looked somewhat interesting. Little did I know at the time, that its practically a legend. Let's just say that even though my pile of unread books is quite large, this one sat at the top of the heap. Its actually a pretty old book, originally published in 1975, and republished in 1995 as a 20th anniversary edition. In computer terms, that is ancient. But the focus of the book is not technology, it's people. The subtitle is "Essays on Software Engineering", but more accurately it should be "Essays on Software Engineers". It consists of 19 essays, 15 of which are original to the 1975 printing about various topics. Let me just say that this should be required reading for anyone in the field, especially managers. With that said however, I'm not sure I could really appreciate this book, or the points that it tries to make, had I not been in the industry for a few years, and been involved with a few larger projects.
The basic premise of the book, if you had to boil the whole thing down to one sentence, is that "People and months aren't interchangeable". If you've ever been involved in a large software project, you know that the man month is the measure dejur among managers. How many man months will this task take, how many will that task take. Then, when the project gets behind schedule, as almost all projects do, the manager rides in on his horse and reassigns some "resources" (as if people can be simply reassigned like a projector) in order to get things back on schedule. After all, if a task is slated for 3 man months by 2 people, then 6 people ought to be able to complete it in 1. At the first company I worked for out of college, we referred to this as Mongolian Horde Syndrome. Just keep throwing people at it, and eventually you'll be able to get past the Great Wall. It almost never works. It's Brooks Law... Adding manpower to a late project makes it later.
With all this said, I highly recommend it. It's a fast read, it's actually a fun read today, because he does refer to technology of the 1970's, and some of the things that they had to do, and it's just amazing. The last few chapters are especially interesting taking the whole book in context, because he goes back and reevaluates what he said in the 1970's, through the magnifying glass of the 1990's, and its very insightful. Of course, even the magnifying glass of the 1990's is old. Some technologies that were just beginning when he wrote the anniversary essays have now come to fruition, and some technologies are just now being born. It would be interesting to see a 30th anniversary edition where he goes back yet again.
Coincidentally, when I was finishing up this book, I saw a post on Slashdot pointing to a review on the book here. He goes into much more detail regarding each chapter, and if you don't plan on reading the book, at least read that article to get an overview. It might just wet your appetite enough to get it.
Post a Comment
Home: Wauwatosa, WI, United States
I'm a Software Consultant in the Milwaukee area. Among various geeky pursuits, I'm also an amateur triathlete, and enjoy rock climbing. I also like to think I'm a political pundit.
View My Profile
Previous PostsHow Microsoft Lost the API War
The Wonders of VI
When Email is Misrouted
The Blind Leading the Drunk?
Personal LinksCarnival of the Badger
The Coding Monkey
Blog Critics Reviews
Design By maystar