If you’ve spent enough time in the middle of any project, you’ve seen it happen. The once promising idea and the brilliant plan created over many, many meetings to execute it was perfect…when it was just that. Then it had to face real life. It did, you blinked, it’s now a year later, the project is somehow a year delayed, management has thrown a squadron of people at it and the goals have shifted from lofty to “Get this out of the door.”
And so it was back in the early 60s when Fred Brooks became the manager of the IBM OS/360 software package. The lessons learned as he produced that software were then compiled in the now-seminal tome The Mythical Man-Month. The chief of them has also been more succinctly presented on developer favorite Brooks’s Law, which simply says “Adding manpower to a late software project makes it later.”
In the fast-paced and ever-changing world of software development, one can wonder how is it that a book first released on the era of polyester pants and avocado green kitchens can somehow still be relevant, especially when its latest revision was released in 1995, when this newfangled language called PHP had just been released. And it’s admittedly curious to read through it and note the references to a time gone by in the history of development, like dev teams having secretaries and an ever-present struggle to minimize the amount of computer time required. But as you read through it you learn that the core elements that it presents are still very relevant for a simple reason. One that I’m not the first to notice.
Software development has changed. The people involved the software development haven’t.
So when you bring more of them to a project, you still have to train them and account for the time that takes, you still have to be mindful on how the end product integrates with other components, you still have to make sure that you’re facilitating proper communication and that you haven’t accidentally bloated your team to the point where more time is spent managing them and how they interact over actual development.
It also doesn’t hurt that most of the items highlighted by Brooks can be just as applicable on other fields. Though the book itself is unsurprisingly focused on software development, and enterprising project manager should be able to apply many of the lessons presented therein on their own projects. Especially on the closing phases where the urge to release hits hard and manpower is paradoxically increased in order to tackle items that need improvement, and which end up being the project’s equivalent to the Heisenbug.
I went into the book with low expectations. As low as they can be when the technology-oriented tome you hold on your hands has a yellow cover that has aesthetically yellowed throughout its long existence and smells enjoyably like only a second-hand bookstore can. And that was good, because low expectations means that hype doesn’t get in the way of what is still a learning experience that many people could benefit from.
