The biggest problem of The Mythical Man Month is that the valuable lessons are buried amongst a pile of historical technological references which severely bog down the text. Perhaps I should have anticipated this for a book written in 1975. Various lessons are still applicable, but it is so tedious to filter them out that the book was a struggle to finish.
Reading about version control using five foot high stacks of workbooks was entertaining (especially for a reader who can barely remember dial-up internet), but ultimately that section is outdated and irrelevant to modern software development practices. Brooks dedicates entire chapters on how to work collaboratively to share machine time on a computer, recommends a lead developer has a support team of ten (many who perform secretarial tasks) and makes dozens of now-obscure references to the technology of the time.
I am perhaps at risk of sounding unjust. The software development industry lacks a culture of studying its history and we can rely on these works to experience the past. To Brooks’ credit, many of the lessons have been so universally adopted that reading the text becomes a matter of ‘this guy just reiterates best practice’.
Some of these now-common practices include: Maintain conceptual integrity, rapid prototyping, architecture and implementation should be done in parallel, recognize that change is inevitable. Many of these points are enshrined in the agile manifesto: his assertion that “one always has, at every stage in the process, a working system” is core to the agile way of emphasizing working software over documentation.
The most pervasive lesson of the book is enshrined in the title and known as Brooks’s Law: you cannot add more people to a project and expect a proportional reduction in time. Most who have attempted to deliver a software project gone awry have learned this lesson and most have met a project manager who has not.
We have it a lot easier today than during era of systems programming. Brooks’ law is rooted in factors such as:
- complex programming tasks “cannot be perfectly partitioned into discrete tasks”
- any change to teams will cause productivity to decrease during initial disruption
- exponentially increasing communication overhead as teams grow
But today we live in a world where thousands of developers effectively and ‘rapidly’ develop complex applications: what has changed since the 70s?
Back in the day a ‘complex programming task’ meant a big monolithic system. Today, the trend in software development is to emphasize decoupling of systems and teams. Take the popularity of the microservice architecture: a large group can develop a complex system when they work at breaking it up into isolated, independent tasks and subdivide their workforce in the same way.
Communication is quicker, thanks to the internet. Workbooks do not need to be mailed to other offices, we can just push to git and instantly message our colleagues. The exponentially increasing communication overhead still exists, but is managed by publishing interface documentation for individual system components.
With the right technical architecture, the right communication tactics, the right levels of oversight and management, engineering teams can scale. So yes, the man-month is a myth: merely throwing people at a problem will likely not help; but today we have more tactics that will help us mitigate the effect than ever before.
Most of what is worth learning from The Mythical Man Month has been repeated countless times since. To get the benefit, read the second chapter, a summary, or even the consolidated list of propositions released in the 20th anniversary edition. That said, it delivers a perspective on how much has improved and how little has changed in the last few decades, so if you want to marvel at the realities of work life forty years ago, go ahead and skim the book.