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.
4 comments:
I'm wondering how one might define "easy to create". I can understand making a model on how to build high quality software that is affordable and maintainable - there has to be some sort of algorithm or model for that - but how do we define "easy to create" and develop a single broad method to make the software so? Doesn't this factor often depend more specifically on the flashes of insight of the engineers who are working on it?
It seems that a fundamental economic principle is highlighted here; which is the law of decreasing marginal returns. It seems that with software engineering, the point at which it is inefficient to add another worker is reached earlier. That point is defined when the marginal cost to produce one more unit of output exceeds the marginal benefit of the product.
I think that this idea of "adding one more engineer" is true in many creative/technical disciplines. You must teach all new workers about how things are done, company traditions, expectations, income plans, health plans. It might be a good model that part of the production team is a small sub-team whose job it is to get new workers up to speed.
On another note, I really enjoyed our conversations in class about different economic models, this is a great follow up post. Thanks
We need to talk about agile programming. It is a set of practices that are relevant well beyond software development. In the digital age, project management that has a strong electronic component to it is going to be the norm, and not just for those punching out lines of Python or PHP.
Post a Comment