Tuesday, October 19, 2010
Old Book, New Book #25: Mythical Man-Month -> Catching Fire
I read most of "The Mythical Man-Month" during my flights to and from Hawaii, and then took my time getting around to finishing it after I got home from the trip. Despite most of the book being written in 1975 (this was the 20th anniversary edition that also included essays from 1986 and 1995), it definitely had some insightful principles for managing large software development projects.
The book's namesake premise is that the idea that the amount of work to be done in a software project can be measured simply in "Man-Months", i.e. the amount of work that one man does in a month. And that a project that can be done by 5 men (or women) in 10 months (50 Man-Months) could be done equally by 10 men (or...who are we kidding, like you could find 10 woman software developers) in 5 months. Not so! says the author. Adding more people to a software project requires extra work to split the work up between developers, and more work to keep more people in communication regarding the project. This problem is exacerbated when trying to add more people to a project that has fallen behind schedule. The author states a theory that "Adding more people to a late project makes it even later."
This might be the first book I've ever read on the topic of software engineering that wasn't a textbook I was reading for a class (and actually this book was actually recommended as supplemental reading for a class I took). I found a couple of the author's thoughts on what makes a programmer a programmer to be interesting. Early on he says one of the challenges of software development is the requirement of perfection. Compilers don't intuit things. Corner cases have to be addressed. In computer programming, the devil truly is in the details and a successful program has to be built all the way in order to be robust and reliable. So programmers tend to be people who are perfectionists and who can deal with that requirement for perfection and completeness.
In a later section, he speaks of asking programmers "Where is next November?" and goes on to say that most programmers are very spatial thinkers and they generally have spatial interpretations of time. That certainly struck a chord with me, given my own mental maps of numbers of calendars.
Anyway, it was an interesting read and gave me some things to think about in my own work in the large-scale complex software development environment there.
Having finished off a book of nerdy essays, I've moved back to lighter fare, borrowing "Catching Fire", the 2nd book in the Hunger Games series from a friend. I enjoyed the first one and it was a quick read, so I'm hoping for more of the same in the 2nd installment.