Good cooking fakes time. If you are made to wait, it is to serve you better, and to please you
MENU OF RESTAURANT ANTOINE. NEW ORLEANS
More projects go wrong because of lack of time than other factors.
- Estimation techniques are poorly developed (optimistically assuming that “all will go well”)
- Estimation techniques fallaciously confuse effort with progress (assuming men and time are interchangeable)
- We are uncertain of our estimates
- Schedule progress is poorly monitored
- When schedule delay is identified, the natural (and traditional) response is to add manpower (which makes matters worse, much worse)
All programmers are optimists. Why?, maybe…
- this modern sorcery (programming) especially attracts those who believe in happy endings and fairy godmothers.
- the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal.
- it is merely that computers are young, programmers are younger, and the young are always optimists.
- IDEA – a program comes into existence first as an ideal construct, built outside time and space, but complete in the mind of the author
- IMPLEMENTATION – built in time and space, by pen, ink, and paper, or by wire, silicon, and ferrite.
- INTERACTION – when the user is making use of it
Traditional activities reveal the incompleteness and inconsistencies of our ideas during implementation, which takes time and sweat both because of the physical media and because of the inadequacies of the underlying ideas.
On the other hand, the programmer builds from pure thought-stuff, in a very tractable medium. Because of it, we expect few difficulties in implementation; hence our pervasive optimism. But our ideas are faulty, so have bugs; hence our optimism is unjustified.
In a single task, the assumption that “all will go well” has a probabilistic effect on the schedule where it might not go well.
A large programming effort, however, consists of many tasks, some chained end-to-end. The probability that each will go well becomes vanishingly small.
It is erroneous to consider that people and months are interchangeable, which is reflected in the unit of effort used in estimating and scheduling: the man-month.
- Cost varies according to the number of men and the number of months.
- Progress does not.
The man-month as a unit for measuring the size of a job is a dangerous and deceptive myth.
TYPES OF DIFFERENT TASKS AND ITS MEN-TIME INTERCHANGEABILITY:
- Tasks that can be partitioned (with no need for communication among workers):
Men and months are interchangeable commodities as it presents workers with no communication among them.
EXAMPLE: reaping wheat or picking cotton
- Tasks that cannot be partitioned because of sequential constraints
The application of more effort has no effect on the schedule.
EXAMPLE: The bearing of a child takes nine months, no matter how many women are assigned.
- Tasks that can be partitioned (with needs for communication among the subtasks)
The effort of communication must be added to the amount of work to be done. Therefore the best that can be done is somewhat poorer than an even trade of men for months.
The added burden of communication is made up of two parts
- TRAINING: in the technology, the goals of the effort, the overall strategy, and the plan of work. This training cannot be partitioned, so this part of the added effort varies linearly with the number of workers.
- INTERCOMMUNICATION: If each part of the task must be separately coordinated with each other part/ the effort increases as n(n-I)/2. Three workers require three times as much pairwise intercommunication as two; four require six times as much as two.
If, moreover, there need to be conferences among three, four, etc., workers to resolve things jointly, matters get worse yet. The added effort of communicating may fully counteract the division of the original task.
Software development is inherently a systems effort—an exercise in complex interrelationships—communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning. Adding more men then lengthens, not shortens, the schedule.
Sequential constraints especially affect component debugging and system test. The time required depends on the number and subtlety of the errors encountered. (Theoretically this number should be zero.)
>> We expect less bugs than it turns out to be
>> testing runs out of (mis)scheduled time
Rule of thumb for scheduling a software task:
- l/3 planning
- l/6 coding
- l/4 component test and early system test
- l/4 system test, all components in hand.
This differs from conventional scheduling in several important ways:
- The fraction devoted to planning is larger than normal. Even so, it is barely enough to produce a detailed and solid specification, and not enough to include research or exploration of totally new techniques.
- The half of the schedule devoted to debugging of completed code is much larger than normal.
- The part that is easy to estimate, i.e., coding, is given only one-sixth of the schedule.
Not assigning enough time for test is disastrous. Delay on testing phase comes at the end, so it is realized in the verge of delivery date. Bad news, late and without warning; for both customers and managers.
- Direct costs on development project.
- Indirect costs to the functionalities for which this project is being developed.
Urgency on the managerial side affects the schedule, but has nothing to do with the real time required for development. Once estimated time has been passed, customer has two choices—wait or “eat it raw”.
False scheduling to match client’s desired date is much more common in Software Development than elsewhere in engineering.
It is extremely complicated to make a real plausible estimation derived by no quantitative method, not enough data which is accepted by managers.
Clearly two solutions are needed. We need to develop and publicize productivity figures, bug-incidence figures, estimating rules, and so on. The whole prof ession can only profit from sharing such data.
Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wishderived estimates.
Regenerative Schedule Disaster
Problem: a project behind schedule.
- Include extra people to meet time requirements. This will imply additional –and not available time- for training, additional testing,… creating a new delay.
- Reschedule, allowing time enough to ensure the work to be carefully and thoroughly done (so, no need for future rescheduling)
- Trim the task (which in practice trends to occurred anyway when adding additional people)
Oversimplifying outrageously: BROOK’S LAW:
“Adding manpower to a late software project makes it later”
This then is the demythologizing of the man-month:
- The number of months of a project depends upon its sequential constraints.
- The maximum number of men depends upon the number of independent subtasks.
From these two quantities one can derive schedules using fewer men and more months. (The only risk is product obsolescence.) One cannot, however, get workable schedules using more men and fewer months. More software projects have gone awry for lack of calendar time than for all other causes combined.