If you've ever worked on a software development project under a time crunch, then you may have heard the phrase "mythical man month."
This phrase will often get uttered by a well-read team member when presented with a business stakeholder who wants to throw more bodies at the project to make it go faster. As often as the concept comes up, it never really lives beyond my under-the-breath mutterings. I tend not to share it with clients. Because how do you explain the “mythical man month” to Mr. CEO In A Hurry?
Well for starters, it’s helpful to read the essay. Frederick P. Brooks warns us that in software, man hours and months are not interchangeable. You can’t add more men in order to make a project go faster. CEOs and businessey types are prone to thinking this way because it’s true in most other production settings (e.g. manufacturing or farming).
Adding more labor to go faster doesn't work in software for two reasons:
- Programming tasks are not partitionable.
- Programming requires communication.
“Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them.” Here’s a picture for graphy types:
If the tasks can’t be partitioned, they have sequential constraints. This means that increasing the team won’t bring any speed gains.
i.e. No matter how many women you add to a baby-making team, it will still take 9 months to produce that baby!
There are two types of communication: training-related and task-related. The real drain is task-related intercommunication, which increases level of effort by n(n-1)/2 with each new team member.
So team-of-3 requires three times the intercommunication of team-of-2.
And team-of-4 requires six times the intercommunication of team-of-2.
Any gains in task completion are saddled with huge increases in project communication overhead. And so you are no better off deadline-wise.
Wonder if I ought to carry these graphs around — ready to whip out during any client meeting. Or maybe I should practice drawing them on the whiteboard.
It’s hard to believe this book was written in 1975. So much of what Brooks describes are concepts and practices that didn't even have a name yet.
Some passages read like software engineering history (sharing machine time and employing documentation secretaries?). And others like The Mythical Man Month read as if they were written yesterday.
Well... except for the “Man” part.
