The Mythical Man-Month: Debunking the Myth of Adding Manpower to Late Software Projects, Schemes and Mind Maps of Computer Programming

Download The Mythical Man-Month: Debunking the Myth of Adding Manpower to Late Software Projects and more Schemes and Mind Maps Computer Programming in PDF only on Docsity!

The Mythical Man-Month

14 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? First, our techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite un- true, i.e., that all will go well. Second, our estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable. Third, because we are uncertain of our estimates, software managers often lack the courteous stubbornness of Antoine's chef. Fourth, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering. Fifth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse. More fire re- quires more gasoline, and thus begins a regenerative cycle which ends in disaster. Schedule monitoring will be the subject of a separate essay. Let us consider other aspects of the problem in more detail.

Optimism

All programmers are optimists. Perhaps this modern sorcery espe- cially attracts those who believe in happy endings and fairy god- mothers. Perhaps the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal. Perhaps it is merely that computers are young, programmers are younger, and the young are always optimists. But however the selection process works, the result is indisputable: "This time it will surely run," or "I just found the last bug." So the first false assumption that underlies the scheduling of systems programming is that all will go well, i.e., that each task will hike only as long as it "ought" to take.

Optimism 15

The pervasiveness of optimism among programmers deserves more than a flip analysis. Dorothy Sayers, in her excellent book, The Mind of the Maker, divides creative activity into three stages: the idea, the implementation, and the interaction. A book, then, or a computer, or a program comes into existence first as an ideal construct, built outside time and space, but complete in the mind of the author. It is realized in time and space, by pen, ink, and paper, or by wire, silicon, and ferrite. The creation is complete when someone reads the book, uses the computer, or runs the program, thereby interacting with the mind of the maker. This description, which Miss Sayers uses to illuminate not only human creative activity but also the Christian doctrine of the Trinity, will help us in our present task. For the human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation. Thus it is that writing, experimentation, "working out" are essential disciplines for the theoretician. In many creative activities the medium of execution is intract- able. Lumber splits; paints smear; electrical circuits ring. These physical limitations of the medium constrain the ideas that may be expressed, and they also create unexpected difficulties in the implementation. Implementation, then, takes time and sweat both because of the physical media and because of the inadequacies of the under- lying ideas. We tend to blame the physical media for most of our implementation difficulties; for the media are not "ours" in the way the ideas are, and our pride colors our judgment. Computer programming, however, creates with an exceed- ingly tractable medium. The programmer builds from pure thought-stuff: concepts and very flexible representations thereof. Because the medium is tractable, we expect few difficulties in implementation; hence our pervasive optimism. Because our ideas are faulty, we 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. It might indeed go as

The Man-Month 17

When a task cannot be partitioned because of sequential con-

straints, the application of more effort has no effect on the sched-

ule (Fig. 2.2). The bearing of a child takes nine months, no matter

how many women are assigned. Many software tasks have this

characteristic because of the sequential nature of debugging.

Fig. 2.2 Time versus number of workers—unpartitionable task

In tasks that can be partitioned but which require communica-

tion 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 (Fig. 2.3).

18 The Mythical Man-Month

Men

Fig. 2.3 Time versus number of workers—partitionable task requiring communication

The added burden of communication is made up of two parts,

training and intercommunication. Each worker must be trained 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.^1

Intercommunication is worse. 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 and bring us to the situation of Fig. 2.4.

20 The Mythical Man-Month

smaller than it turns out to be. Therefore testing is usually the most mis-scheduled part of programming. For some years I have been successfully using the following 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:

1. The fraction devoted to planning is larger than normal. Even so, it is barely enough to produce a detailed and solid specifi- cation, and not enough to include research or exploration of totally new techniques.
2. The half of the schedule devoted to debugging of completed code is much larger than normal.
3. The part that is easy to estimate, i.e., coding, is given only one-sixth of the schedule.

In examining conventionally scheduled projects, I have found that few allowed one-half of the projected schedule for testing, but that most did indeed spend half of the actual schedule for that purpose. Many of these were on schedule until and except in system testing.^2 Failure to allow enough time for system test, in particular, is peculiarly disastrous. Since the delay comes at the end of the schedule, no one is aware of schedule trouble until almost the delivery date. Bad news, late and without warning, is unsettling to customers and to managers. Furthermore, delay at this point has unusually severe finan- cial, as well as psychological, repercussions. The project is fully staffed, and cost-per-day is maximum. More seriously, the soft- ware is to support other business effort (shipping of computers, operation of new facilities, etc.) and the secondary costs of delay- ing these are very high, for it is almost time for software shipment.

Regenerative Schedule Disaster 21

Indeed, these secondary costs may far outweigh all others. It is therefore very important to allow enough system test time in the original schedule.

Gutless Estimating

Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices— wait or eat it raw. Software customers have had the same choices. The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save— burned in one part, raw in another. Now I do not think software managers have less inherent courage and firmness than chefs, nor than other engineering man- agers. But false scheduling to match the patron's desired date is much more common in our discipline than elsewhere in engineer- ing. It is very difficult to make a vigorous, plausible, and job- risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the 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 wish- derived estimates.

Regenerative Schedule Disaster What does one do when an essential software project is behind schedule? Add manpower, naturally. As Figs. 2.1 through 2.4 sug- gest, this may or may not help.

 - Regenerative Schedule Disaster 

• Figure 2,
• Figure 2.

24 The Mythical Man-Month

3. Reschedule. I like the advice given by P. Fagg, an experienced hardware engineer, "Take no small slips." That is, allow enough time in the new schedule to ensure that the work can be carefully and thoroughly done, and that rescheduling will not have to be done again.
4. Trim the task. In practice this tends to happen anyway, once the team observes schedule slippage. Where the secondary costs of delay are very high, this is the only feasible action. The manager's only alternatives are to trim it formally and carefully, to reschedule, or to watch the task get silently trimmed by hasty design and incomplete testing. In the first two cases, insisting that the unaltered task be completed in four months is disastrous. Consider the regenerative effects, for example, for the first alternative (Fig. 2.8). The two new men, however competent and however quickly recruited, will re- quire training in the task by one of the experienced men. If this takes a month, 3 man-months will have been devoted to work not in the original estimate. Furthermore, the task, originally partitioned three ways, must be repartitioned into five parts; hence some work already done will be lost, and system testing must be lengthened. So at the end of the third month, substantially more than 7 man- months of effort remain, and 5 trained people and one month are available. As Fig. 2.8 suggests, the product is just as late as if no one had been added (Fig. 2.6). To hope to get done in four months, considering only training time and not repartitioning and extra systems test, would require adding 4 men, not 2, at the end of the second month. To cover repartitioning and system test effects, one would have to add still other men. Now, however, one has at least a 7-man team, not a 3-man one; thus such aspects as team organization and task divi- sion are different in kind, not merely in degree. Notice that by the end of the third month things look very black. The March 1 milestone has not been reached in spite of all

26 The Mythical Man-Month

straints. 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 sched-

ules using more men and fewer months. More software projects

have gone awry for lack of calendar time than for all other causes

combined.