Adding manpower to a late software project makes it laterBrooks coined this maxim while working as a software engineer at IBM during the 1950s and 60s. He noticed that large software projects tended to run behind schedule, and that a manager's first instinct was to add more manpower. After all, this works in many other fields. For example, if you need to pick a crop of peaches, the more workers you employ, the faster it will get done. John Steinbeck's The Grapes of Wrath describes how the perfect partitioning of this kind of manual labor during the Dust Bowl of the 1930s led to the exploitation of workers, movingly illustrating the ugly side of capitalism. Brooks explains how software engineering is rarely partitioned perfectly into smaller increments of tasks, so that adding more workers actually delays a late project even more. Each additional worker requires "ramp up" time to become integrated into the project, plus additional personnel and communication costs, factors that managers of the era were ignoring.
Amazingly, though The Mythical Man-Month was printed in 1975, its lessons remain relevant and it is still considered a classic text in the area. Companies often repeat the same mistakes, leading to massive failures known as a death march:
Death march projects are becoming increasingly common in the software industry. The symptoms are obvious: The project schedule, budget, and staff are about half of what is necessary for completion. The planned feature set is unrealistic. People are working 14 hours a day, six or seven days a week, and stress is taking its toll. The project has a high risk of failure, yet management is either blind to the situation or has no alternative.Somehow, software engineering has bedeviled managers for years -- we still don't have a good handle on how to build high quality software that is affordable, maintainable, and easy to create. Modern software development has tried to overcome these obstacles, leading to the open source movement championed by The Cathedral and the Bazaar, alternative software development methodologies, and yet more spectacular failures.
This is one of the reasons why the digital economy is so exciting -- perhaps a different economic model will help us learn how to create better software. Already, some pearls of wisdom from Eric Raymond, such as
"Release early. Release often. And listen to your customers."are permeating software development. Google doesn't "ship" products, nor does it sell them. They release them as betas, collect feedback, and constantly integrate new features. Yet, they are a fabulously successful company. Perhaps more exciting lessons are around the corner as we explore additional ramifications of the digital economy.