02. The Mythical Man-Month

More software projects have gone awry for lack of calendar time than for all other causes combined.

Why is this cause of disaster so common?

1. Our estimation techniques assume that all will go well, i.e. each task will take only as long as it “ought” to take.
2. Our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable.
3. Because we are uncertain of our estimates, software managers often lack the courteous stubbornness - if you’re made to wait, it is to serve you better, and to please you.
4. Schedule progress is poorly monitored.
5. When schedule slippage is recognized, the natural (and traditional) response is to add manpower, which is like dousing a fire with gasoline.

Optimism

For human makers, the incompletenesses and inconsistencies of our ideas become clear only during implementation.

Because the medium for computer programming is tractable (unlike lumber splitting, or paint smearing, or electrical circuits ringing), we expect few difficulties in implementation; hence our pervasive optimism.

A large programming effort consists of many tasks, some chained end-to-end. The probability that each will go well becomes vanishingly small.

The Man-Month

Cost does vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable.

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them

The added burden of communication is made up of two parts, training and intercommunication:

• Training in the technology, the goals of the effort, the overall strategy, and the plan of work. Training cannot be partitioned, so this part of the added effort varies linearly with the number of workers.
• Intercommunication is worse. If each part of the task must be separately coordinated with each other part, the effort increases as \(\frac{n(n-1)}{2}\)

Systems Test

Optimism makes us expect fewer bugs, hence testing is usually the most mis-scheduled part.

Rule of thumb for scheduling a software task: planning - \( \frac{1}{3} \), coding - \( \frac{1}{6} \), component test & early system test - \( \frac{1}{4} \), system test with all components - \( \frac{1}{4} \).

Failure to allow enough time for system test is peculiarly disastrous because delay at this point has severe financial cost (fully staffed, secondary cost of efforts dependent on task completion).

Regenerative Schedule Disaster

Suppose a task is estimated at 12 man-months and assigned to three men for four months, and that there are measurable mileposts A, B, C, D, which are scheduled to fall at the end of each month

Now suppose A is only reached after 2 months. What are the alternatives facing the manager?

• Assume that the task must be done on time
  • Assume only the first part of the task was mis-estimated
    • 9 man-months of effort and 2 months remain.
    • We need 4.5 men, therefore add 2 men to the 3 assigned.
  • Assume that the whole estimate was uniformly low.
    • 18 man-months of effort and 2 months remain.
    • 9 men will be needed. Add 6 men to the 3 assigned.
• Reschedule such that work can be done carefully and thoroughly, and that rescheduling won’t have to be done again.

  I don’t understand this argument. What prevents the maanager from making the same mis-estimates the \(n^{th}\) time round?

• Trim the task (in practice, tends to happen anyway).
  • Where the secondary costs of delay are very high, this is the only feasible action.

Analysis of a Regenerative Disaster

• The 2 new men will need to be trained by 1 of the 3 experienced men.
• If training takes 1 month, 3 man-months have been used in work not in the original estimate.
• The task must now be repartitioned into 5 parts. System testing must be lengthened.
• At the end of month #3, more than 7 man-months remain. There are 5 trained people and 1 month available.
• The product is at least as late as if no one had been added.

Oversimplifying outrageously, we state Brooks’s Law: Adding manpower to a late software project makes it later.