Trying to restate the main points of Chapter 2 of "The Mythical Man-Month" mostly in my own words:
The majority of software projects fail due to lack of calendar time.
Reasons:
- Bad estimation techniques, exacerbated by not accounting for intermediate risks.
- Estimates conflate effort with progress, not recognizing that calendar time cannot be traded for workers.
- Lack of confidence in estimates leads managers to over promise.
- Bad progress monitoring. Software engineering fails to incorporate best practices from other engineering disciplines.
- When a project starts to fall behind, often new people are added, but this actually makes things worse.
Optimism
"All programmers are optimists". The flexibility of programming may contribute to this: "The programmer builds from pure thought-stuff: concepts and very flexible representations thereof." Having the power to do anything makes you think that you can do anything easily. However, then problems with our ideas creep in as bugs, making that optimism unrealistic.
(This great flexibility implies a big search space, and a need -- or at least possibliity -- for more creativity. Is it right that programmers are more prone to over optimism, accounting for the novelty of the problem being solved?)
In a big project with many subtasks, the probability that everything will go well is teeny. (Brooks says, "The probability that each will go well...", but I guess he meant, "The probability that all will go well...")
The SWE-Month
While cost necessarily increases with both the time taken and the number of workers, progress does not. "Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth."
The two are interchangeable only if work can be divided amongst workers without requiring communication between workers. "[I]t is not even approximately true for systems programming."
If a task is sequential by nature, it cannot be partitioned and so clearly cannot be sped up by adding more workers. Debugging can make tasks sequential. (Huh? Fixing one bug reveals another??)
For tasks that can be partitioned but require communication, the cost of communication must be accounted for.
Two types of communication costs:
- Training: "[V]aries linearly with the number of workers" (Clearly part of it does -- the trainee's own time -- but since training materials can be reused, other parts are sublinear.)
- Intercommunication: "If each part of a the task must be separately coordinated with each other part, the effort increases as n(n-1)/2."
The extra cost from communication may be so high that it actually ends up slowing the project down.
Systems test
(Most impacted by sequential constraints because it needs to happen after rest of system is complete? Can test driven development help here?)
Rule of thumb for planning software schedule:
- 1/3 planning
- 1/6 coding
- 1/4 component test, early system test
- 1/4 full system test
Although it's uncommon to budget half of project time for testing, in reality, the author observed testing to actually take this amount of time for most projects. Under budgeting for testing can be particularly disastrous because the bad news comes close to the promised delivery date, when the cost per day is at maximum and failures are most visible to customers.
Giving into customer/management pressure to overpromise: gutless estimating
Lacking confidence in their estimates, managers find it hard to push back on customer/management desire for unreasonably optimistic planned delivery dates. The solution is to improve those estimation methods but also to recognize that even a rough estimate is better than wishful thinking and so to push back.
Regenerative Schedule Disaster
Brooks's Law: Adding manpower to a late software project makes it later.
