2

The Mythical ISAan-hAonih

Good cooking

takes time. If

serve j/ou better,

and

you are made

to please

to wait,

it is to

you.

MENU OF RESTAURANT ANTOINE, NEW ORLEANS

13

The Mythical Man-Month

14

More software
than for
so

all

projects

have gone awry for lack of calendar time

other causes combined.

Why

this cause of disaster

is

common?
First,

our techniques of estimating are poorly developed.

seriously, they reflect

true,

i.e.,

that

all

will

an unvoiced assumption which

is

More

quite un-

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

is to add manpower. Like dousing a fire with

makes matters worse, much worse. More fire remore gasoline, and thus begins a regenerative cycle which

traditional) response

gasoline, this

quires

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
this modern sorcery espehappy endings and fairy godmothers. 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

All

programmers are optimists. Perhaps

cially attracts

those

works, the result

"I just

found the

So the

is

who

believe in

indisputable: 'This time

last

first false

will surely run,'' or

assumption that underlies the scheduling of

systems programming

is

take only as lon^ as

"ought"

it

it

bug."
that all will ^o well,
to take.

i.e.,

that each task will

optimism

15

The pervasiveness of optimism among programmers deserves

more than a flip analysis. Dorothy Sayers, in her excellent book,

Mind

The

of the

Maker, divides creative activity into three stages:

the idea, the implementation, and the interaction.

book, then,

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
or a computer, or a program

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

human makers of
and inconsistencies of our ideas

Trinity, will help us in our present task. For the

things, the incompletenesses

become

clear only during implementation.

Thus

it is

that writing,

experimentation, ''working out'' are essential disciplines for the

theoretician.

In
able.

many creative activities

Lumber

splits;

the

medium of execution is intract-

paints smear; electrical circuits ring. These

physical limitations of the

medium

constrain the ideas that

be expressed, and they also create unexpected

may

difficulties in the

implementation.

Implementation, then, takes time and sweat both because of

the physical media and because of the inadequacies of the underlying ideas.

We tend to blame the physical media for most of our

implementation

way

difficulties; for

the media are not

''ours'' in

the

the ideas are, and our pride colors our judgment.

Computer programming, however, creates with an exceedtractable medium. The programmer builds from pure

ingly

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

In a single task, the

probabilistic effect

assumption that

on the schedule.

It

all

is

unjustified.

will

go well has a

might indeed go as planned,

16

The Mythical Man-Month

for there

a probability distribution for the delay that will be

is

encountered, and ''no delay" has a

gramming

effort,

finite probability.

many

however, consists of

end-to-end. The probability that each will

A large pro-

some chained
go well becomes vantasks,

ishingly small.

The Man-Month
The second

mode

fallacious thought

is

expressed in the very unit

of effort used in estimating and scheduling: the

man-month. Cost
men and the

does indeed vary as the product of the number of

number of months. Progress does not. Hence the man-month

for measuring the size of a job

implies that

is

men and months

as a unit

a dangerous and deceptive myth.

It

are interchangeable.

Men and months are interchangeable commodities only when

a task can be partitioned
tion

among them

cotton;

it is

among many workers

(Fig. 2.1).

This

is

with no communica-

true of reaping

wheat or picking

not even approximately true of systems programming.

Men

Fig. 2.1

Time versus number

of workers

perfectly partitionable task

The Man-Month

17

When a

task cannot be partitioned because of sequential con-

straints, the

appHcation of more effort has no effect on the sched-

ule (Fig. 2.2).

The bearing

how many women

of a child takes nine months,

are assigned.

Many

no matter

software tasks have this

characteristic because of the sequential nature of debugging.

_L

Men

Time versus number

Fig. 2.2

of workers

unpartitionable task

In tasks that can be partitioned but

tion

among

added

to the

can be done

months

which require communica-

the subtasks, the effort of communication must be

amount of work to be done. Therefore the best that

somewhat poorer than an even trade of men for

is

(Fig. 2.3).

18

The Mythical Man-Month

Men

Fig. 2.3

Time versus number

of workers

partitionable task requiring

communication

The added burden

training

of communication

is

made up

of

two

parts,

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

Intercommunication

is

worse.

If

number

of workers.^

each part of the task must be

separately coordinated with each other part, the effort increases 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.,
n(n-l)/2. Three workers require three times as

jointly, matters get worse yet. The added

communicating may fully counteract the division of the
task and bring us to the situation of Fig. 2.4.

workers to resolve things

effort of

original

Systems Test

19

c
o

Men

Fig. 2.4

Time versus number

of workers

task with complex

interrela-

tionships

Since software construction

exercise in
great,

and

it

is

inherently a systems effort

complex interrelationships

communication

an

effort is

quickly dominates the decrease in individual task time

brought about by partitioning. Adding more

men

then lengthens,

not shortens, the schedule.

Systems Test

No

by sequential
component debugging and system test. Furthermore, the time required depends on the number and subtlety of
parts of the schedule are so thoroughly affected

constraints as

number should be zero.

expect the number of bugs to be

the errors encountered. Theoretically this

Because of optimism,

we

usually

The Mythical Man-Month

20

smaller than

turns out to be. Therefore testing

it

is

usually the

most mis-scheduled part of programming.

For some years I have been successfully using the following

thumb

rule of
Vs

for scheduling a software task:

planning

Ve

coding

Va

component

Va

system

test

test, all

and early system test

components in hand.

This differs from conventional scheduling in several important

ways:

The

1.

fraction devoted to planning

larger than normal.

is

Even

cation,

barely enough to produce a detailed and solid specifiand not enough to include research or exploration of

totally

new

so,

it is

2.

The

3.

The

techniques.

half of the schedule devoted to

code

is

much

debugging of completed

larger than normal.

part that

is

easy to estimate,

i.e.,

coding,

given only

is

one-sixth of the schedule.

examining conventionally scheduled projects, I have found

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
In

that

system

testing.^

Failure to allow

enough time

for

system

peculiarly disastrous. Since the delay

schedule, no one
delivery date.
to

is

test, in particular, is

comes

at the

aware of schedule trouble

Bad news,

late

end of the

until almost the

and without warning,

is

unsettling

customers and to managers.

Furthermore, delay at this point has unusually severe finan-

cial,

as well as psychological, repercussions.

maximum. More

The

project

is

fully

staffed,

and cost-per-day

ware

to support other business effort (shipping of computers,

is

operation of

new

is

facilities, etc.)

ing these are very high, for

it is

seriously, the soft-

and the secondary costs of delay-

almost time for software shipment.

Regenerative Schedule Disaster

Indeed, these secondary costs

may

therefore very important to allow

far outweigh
enough system

all

test

others.

21

It is

time in the

original schedule.

Gutless Estimating

Observe that
the patron
it

for the

programmer, as for the chef, the urgency of

may govern

the scheduled completion of the task, but

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 managers. But false scheduling to match the patron's desired date is
much more common in our discipline than elsewhere in engineering. It is very difficult to make a vigorous, plausible, and jobrisking 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 profession can only profit from sharing

such data.
Until estimating
will

need to

is

on

stiffen their

sounder

basis, individual

backbones and defend

managers

their estimates

with the assurance that their poor hunches are better than wishderived estimates.

Regenerative Schedule Disaster

What

when an essential software project is behind

Add manpower, naturally. As Figs. 2.1 through 2.4 sugmay or may not help.

does one do

schedule?
gest, this

The Mythical Man-Month

22

Let us consider an example.^ Suppose a task

man-months and assigned

to three

men

for four

there are measurable mileposts A, B, C, D,

fall at

the end of each

Now

suppose the

months have elapsed

month
first

is

estimated at 12

months, and that

which

are scheduled to

(Fig. 2,5).

milepost

(Fig. 2.6).

What

is

not reached until two

are the alternatives facing

the manager?
1.

Assume

that the task

the

part of the task

must be done on time. Assume that only

was misestimated, so Fig. 2.6 tells the
story accurately. Then 9 man-months of effort remain, and
two months, so AVi men will be needed. Add 2 men to the 3
first

assigned.
2.

Assume

that the task

must be done on time. Assume that the

whole estimate was uniformly low, so that

describes the situation.

Then 18 man-months

and two months, so 9 men

will

be needed.

3 assigned.

Months

Figure 2.5

Fig. 2.7 really

of effort remain,

Add

men

to the

Regenerative Schedule Disaster

^'-

__
r-

"

f.^

"
1

month delay
man/months remain)

(9

m/m

remain

Months

Figure 2.6

(18

Months

Figure 2.7

23

The Mythical Man-Month

24

3.

Reschedule.

like the advice

given by

hardware engineer, 'Take no small

enough time

in the

new

P. Fagg,

slips/'

an experienced
That is, allow

schedule to ensure that the work can

be carefully and thoroughly done, and that rescheduling will

4.

not have to be done again.

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

The manager's only

is

the only feasible action.

alternatives are to trim

carefully, to reschedule, or to

it

formally and

watch the task get

trimmed by hasty design and incomplete

silently

testing.

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 require 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
In the

first

original estimate.

Furthermore, the task, originally partitioned three

ways, must be repartitioned into ^we 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 manmonths 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 division are different in kind, not merely in degree.

Notice that by the end of the third

black.

The March

1 milestone has not

month

things look very

been reached

in spite of all

Regenerative Schedule Disaster

25

Training

complete
2

5 programmers
for 7+ m/m

Months

Figure 2.8

The temptation is very strong to repeat the

cycle, adding yet more manpower. Therein lies madness.
The foregoing assumed that only the first milestone was
misestimated. If on March 1 one makes the conservative assumption that the whole schedule was optimistic, as Fig. 2.7 depicts, one
the managerial effort.

wants

to

add 6 men

just to the original task. Calculation of the

training, repartitioning,

for the reader.

system testing

Without

Adding manpower

number

of

would rescheduling with the

men, unaugmented.

Oversimplifying outrageously,

This then

an exercise

a doubt, the regenerative disaster will

yield a poorer product, later, than

original three

effects is left as

is

to

late

we

state Brooks's

software project makes

the demythologizing of the

months of

a project

depends upon

Law:

it later.

man-month. The
its

sequential con-

26

The Mythical Man-Month

The maximum number of men depends upon the number

From these two quantities one can derive
schedules using fewer men and more months. (The only risk is
straints.

of independent subtasks.

product obsolescence.)
ules using

One cannot, however, get workable sched-

more men and fewer months. More software

have gone awry for lack of calendar time than for

combined.

all

projects

other causes