This post is part of a series of posts with my personal notes about the chapters in the book “The mythical man-month” by Frederick P. Brooks. I write these posts as I read through the book, and take notes on the concepts I find more relevant. I do, however, advise reading the book to get the full benefit out of it.
In this second chapter, we go through the projects time and effort estimations, their problems and possible solutions.
Why do we seem to never have enough time to finish a project?
- Estimation techniques are poorly developed;
- Estimation techniques confuse effort with progress, or complexity with time;
- Software producers often prefer to stick to a time estimation instead of a quality requirement;
- Progress is poorly monitored;
- The traditional response to delays is to add more manpower.
Fallacious thought modes
1. Excessive optimism
Programming has a very tractable medium, unlike building or painting, so we tend to expect few difficulties in implementation.
However, because our ideas are faulty, we have bugs, and therefore our optimism is unjustified. Furthermore, the more and/or bigger tasks the project has, the lower the probability that all will go well.
2. The man-month
A “man-month” is a unit used in estimating and scheduling.
Cost varies as the product of man and number of months, however, progress does not.
If we have clearly isolated tasks, like painting walls or transporting goods, where no communication is needed, the “man-month” is a valid unit: the more man we add, the fewer months it takes to finish the project.
However, if a project is not clearly partitionable, the “man-month” unit is inadequate: “the bearing of a child takes 9 months, no matter how many women are assigned“.
In projects whose tasks can not be isolated, we have an added burden/effort of communication, namelly:
- Training: Each worker must be trained in the technology, goals, strategy and plan;
- Intercommunication: Tasks that need to be coordinated increase the effort in
n*(n-1)/2: Three workers require three times more pairwise communication as two.
The added effort in communication may make the increased man-power counter-productive.
When a project slips the estimation, we have four options:
- Assume it will be on schedule henceforth and so it won’t delay any further. Add men according to that small delay;
- Assume the whole estimate was uniformly low, and uniformly increase the remaining tasks effort. Add manpower accordingly;
- Reschedule the delivery date;
- Reduce the scope of the project to the point where the estimates fit into the promised delivery date.
@hgraca 