Fermat's Library | The Mythical Man-Month annotated/explained version.

This essay is part of a collection of essays published in 1975 by B...

Fred Brooks (born in 1931) is an American computer scientist. Brook...

According to a McKinsey-Oxford study, 1/3 of all large software pro...

The formula $\frac{n(n-1)}{2}$ represents the number of all possibl...

This is one of the cornerstones of modern software development meth...

Victor Vyssotsky was a mathematician and computer scientist. He was...

PERT stands for Program Evaluation and Review Technique. It provide...

THE

MYTHICAL

MAN-MONTH

The

above

anextract from

the

Mythical Man-Month

by Frederick

Brooks,

Jr., copyright

1975 liy Addison-Wesley Publishing Company, Inc., Read-

ing, Massachusetts, pages 14-26,

88-94,

153-160,

and

177. Reprinted with

permission. The extract was prepared by the editors of

Datamation

and

pub-

lished

Datamation,

December 1974, pages 44-52.

SCENE FROM PREHISTORY is

quite so vivid as that of the mortal

struggles of great beasts in the tar pits.

In the mind's eye one sees dinosaurs,

mammoths, and saber-toothed tigers

struggling against the grip of the tar.

The fiercer the struggle, the more en-

tangling the tar, and no beast is so

strong or so skillful but that he ulti-

mately sinks.

Large-system programming has over

the past decade been such a tar pit, and

many great and powerful beasts have

thrashed

violen~ly in it. Most have

emerged with running systems-few

have met goals, schedules, and budgets.

Large and small, massive or wiry, team

after team has become entangled in the

tar. No one thing seems to cause the

difficulty-any particular paw can be

pulled away. But the accumulation of

simultaneous and interacting factors

brings slower and slower motion.

Everyone seems to have been surprised

by the stickiness of the problem, and it

is hard to discern-the nature of it. But

we must try to understand it if we are

to solve it.

More software projects have gone

awry for lack of calendar time than for

all other causes combined. Why is this

case of disaster so common?

First, our techniques of estimating

are poorly developed. More seriously,

they reflect an unvoiced assumption

which is quite untrue,

i.e., that all will

go well.

Second, our estimating techniques

fallaciously confuse effort with prog-

ress, hiding the assumption that men

and months are interchangeable.

Third, because we are uncertain of

our estimates, software managers often

HOW

DOES

PROJECT GET TO

BEAYEAR

LATE?

. .

ONE DAY AT A TIME.

By Frederick

Brooks, Jr.

lack the courteous stubbornness re-

quired to make people wait for a good

product.

Fourth, schedule progress is poorly

monitored. Techniques proven and

routine in other engineering disciplines

are

considered

radical

innovations

software engineering.

Fifth, when schedule slippage is rec-

ognized, the natural (and traditional)

response is to add manpower. Like

dousing a fire with gasoline, this makes

matters worse, much worse. More fire

requires more gasoline and thus begins

a regenerative cycle which ends in dis-

aster.

Schedule monitoring will be covered

later. Let us now consider other as-

pects of the problem in more detail.

Optimism

All programmers are optimists. Per-

haps this modern sorcery especially at-

tracts those who believe in happy end-

ings and fairy godmothers. Perhaps the

hundreds of nitty frustrations drive

away all but those who habitually fo-

cus on the end goal. Perhaps it is mere-

that computers are young, program-

mers are younger, and the young are

always optimists. But however the se-

lection process works, the result is in-

disputable: "This time it will surely

run," or

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 take only

long

it "o~ghi" to take.

The pervasiveness of optimism

among programmers deserves more

than a flip analysis. Dorothy Sayers, in

her excellent book,

The Mind

the

Maker,

divides creative activity into

three stages: the idea, the implementa-

tion, and the interaction.

book, then,

or a computer, or a program comes

into existence first as an ideal con-

struct, built outside time and space

but complete in the mind of the au-

thor. It is realized in time and space

by pen, ink, and paper,

by wire,

silicon, and ferrite. The creation

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 cre-

ative activity but also the Christian

doctrine of the Trinity, will help us

our present task. For the human mak-

ers

of things, the incompletenesses and

inconsistencies of our ideas become

clear only during implementation.

Thus it is that writing, experimenta-

tion, "working out" are essential disci-

plines for the theoretician.

In many creative activities the medi-

of execution

intractable. Lumber

splits; paints smear; electrical circuits

ring. These physicad limitations of the

medium constrain the ideas that may

be expressed, and they also create un-

expected diicultie:~ in the irnplemen-

tation.

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 difficulties; for the

media are not "oui-s" in the way the

ideas are, and our pride colors our

judgment.

Computer programming, however,

creates with an exceedingly tractable

medium. The progrsimmer builds from

the product of the number of men and

the number of months. Progress does

not.

Hence the man-month

a unit

for measuring the size

job

dangerous and deceptive myth.

It im-

plies that men and months are inter-

changeable.

Men and months are interchange-

able commodities only when a task can

be partitioned among many workers

with no communication among them

(Fig.

)

This is true of reaping wheat

or picking cotton; it is not even ap-

proximately true of systems program-

ming.

When a task cannot be partitioned

Men

Fig.

The term "man-month" implies

that if one man takes

months to do a

job,

men can do it in one month. This

may

true of picking cotton.

because of sequential constraints, the

application of more effort has no effect

on the schedule. The bearing of a child

takes nine months, no matter how

many women are assigned. Many soft-

ware tasks have this characteristic be-

cause of the sequential nature of de-

Corbat6 of

MIT

points out that a long

project must anticipate a turnover of

20%

per year, and new people must be

both technically trained and integrated

into the formal structure.

Intercommunication is worse. If

each part of the task must be separate-

ly coordinated with each other part,

the effort increases as

n(n-1)

Three

workers require three times as much

pairwise intercommunication as two;

four require six times as much

two.

If, moreover, there need to be confer-

ences among three, four, etc., workers

to resolve things jointly, matters get

worse yet. The added effort of

com-

municatine mav fullv counteract the

division of the original task and bring

us hack to the situation of Fig.

Since software construction is inher-

ently a systems effort-an exercise in

complex

interrelationships-commu-

nication effort is great, and it quickly

Men

pure thought-stuff: concepts and very

buggidg.

Fig.

Even on tasks that can

nicely

flexible representatlions thereof. Be-

tasks

that

partitioned

but

partitioned among people, the additional

cause the medium

tractable, we ex-

which require ~~mn~unication among

communication required adds to the to-

pect few difficulties nn implementation;

thesubtask% the effort of ~~~munica-

tal work, increasing the schedule.

hence our pervasive optimism. Because

tion must be added to the amount of

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 night indeed go as

planned, for there is a probability dis-

tribution for the delay that will be en-

countered, and "no delay" has a finite

probability.

large programming ef-

fort, however, consisits of many tasks,

some chained end-to-end. The prob-

ability that each will go well becomes

vanishingly small.

The

mythical man-month

The second fallacious thought mode

expressed in the very unit of effort

used in estimating and scheduling: the

man-month. Cost docs indeed vary as

work to

done. Therefore the best

that can be done is somewhat poorer

than an even trade of men for months

(Fig.

2).

The added burden of communica-

tion 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,

this part of

the added effort varies linearly with the

number of workers.

Vyssotsky of Bell Telephone

Laboratories estimates that a large

project can sustain a manpower

build-

Men

up of

30%

per year- More than that

Fig.

since software construction is

strains and even inhibits the evolution

complex, the communications overhead

of the essential informal structure and

is great. Adding more men can lengthen,

its communication pathways. F.

rather than shorten, the schedule.

dominates the dec-ease in individual

task

time

brought iboiit by partition-

ing. Adding more nen then lengthens,

not shortens, the schedule.

Systems test

No parts of the schedule are so thor-

oughly affected by sequential con-

straints as component debugging and

system test. Furthermore, the time re-

quired depends or the number and

subtlety of the errors encountered.

Theoretically this number should be

zero. Because of optimism, we usually

expect the number if bugs to be small-

er than it turns oi t to be. Therefore

testing

usually tlie most mis-sched-

uled part of programming.

For some years

have been success-

fully using the following rule of thumb

for scheduling a software task:

planning

coding

component tert and earIy system

test

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

de-

of the schedule.

examining conventionally sched-

uled projects,

have found that few

allowed one-half of the projected

schedule for testing, but that most did

indeed spend half of the actual sched-

ule for that purpose. Many of these

were on schedule until and except in

system testing.

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

aware of

schedule trouble until almost the deliv-

ery date. Bad news, late and without

warning, is unsettling to customers and

to managers.

Furthermore, delay at this point has

unusually severe financial, as well as

psychological, repercussions. The proj-

ect is fully staffed, and cost-perday

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 delaying these are very high,

for it is almost time for software ship-

ment. Indeed, these secondary

costs

may far outweigh all others. It

there-

fore very important to allow enough

system test time in the original sched-

ule.

two

choices~wait or eat it raw. Soft-

ware

customers have had the same

choices.

The cook has another choice; he

can

turn

up theheat. The result is often an

omelette nothing

can

save-burned

one part, raw in another.

Now

do not

think

software man-

agers have less inherent courage and

firmness

than chefs, nor than other

engineering managers. But false sched-

uling to match the patron's desired

date

much more common in our

discipline than elsewhere in engineer-

ing. It

very difficult to make a vigor-

ous, plausible, and job-risking defense

of an estimate that

derived by no

quantitative method, supported by lit-

tie data, and certified chiefly by the

hunches of the managers.

Clearly two solutions are needed.

We need to develop

and

publicize pro-

ductivity figures, bug-incidence figures,

estimating rules, and so on. The whole

profession

can

only profit from sharing

such data.

Until estimating

on a sounder ba-

sis, individual managers will need to

stiffen their backbones, and defend

their estimates with the assurance that

their poor hunches are better than

wishderived estimates.

Fig.

Adding manpower to a project which is late may not help. In this case, suppose

three men on a

nan-month project were

month late. If

takes one of the three

an extra month to t-ain two new men, the project will be just as late as if no one was

added.

5*-

tailed and soliii specification, and

not enough to include research or

exploration of totally new tech-

niques.

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

i---

1-1Ã‘IÃ

Regenerative disaster

What does one

when an essential

software project

behind schedule?

Add manpower, naturally.

Figs. 1

through

suggest,

this

may or may not

help.

Let us consider an example. Suppose

Training

task

estimated at

man-months

complete

and assigned to three men for four

months, and that there are measurable

mileposts A,

which are sched-

uled to fall at the end of each month.

Now suppose the first milepost is not

reached until two months have elapsed.

programmers

What are the alternatives facing the

for

mlm

manager?

Assume that the task must be done

on time. Assume that only the first

I I

part of

the

task

was misestimated.

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.

omelette, prom-

ised in ten minutes, may appear to be

progressing nicely. But when it has not

set in ten minutes, the customer has

Then

man-months of effort re-

main, and two months, so

men

Months

will

needed. Add

men

the

assigned.

Assume

that the

task

must

done

on time. Assume that the whole

estimate was uniformly low. Theft

18 man-months of effort remain,

and

two months, so

men will

needed. Add

men

the

as-

signed.

Reschedule. In

this

case, I like the

advice given by 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 resched-

uling will 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; is the only feas-

ible action. The manager's only al-

ternatives 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 re-

generative effects, for example, for the

first

alternative (Fig.

preceding page).

The two new men, however competent

and however quickly recruited, will re-

quire training in the bisk by one of the

experienced men. If this takes a month,

man-months will have been devoted

to work not in the original estimate.

Furthermore, the task originally parti-

tioned three ways, must be reparti-

tioned into five parts, hence some work

already done will be lost and system

testing must be lengthened.

at the

end of the third month, substantially

more than

man-months of effort re-

main, and 5 trained people and one

month are available.

Fig.

suggests,

the product is just as late as if no one

had been added.

To hope to get done in four months,

considering only training time and not

repartitioning and extra systems test,

would require adding

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

man team. not a 3-man one; thus such

aspects as team organization and task

division are different in kind, not mere-

ly in degree.

Notice that by the end of the third

month things look very black. The

March

milestone has not been

reached in spite of all the managerial

effort. The temptation is very strong to

repeat the cycle, adding; yet more man-

power. Therein lies madness.

The foregoing assumed that only the

first milestone was misestimated. If on

March 1 one makes tile conservative

assumption that the whole schedule

was optimistic one wants to add

men

just to the original task Calculation of

the training, repartitioning, system

testing effects is left as an exercise for

the reader. Without a doubt, the ,re-

generative disaster will yield a poorer

product later, than would rescheduling

with the original three men,

unaug-

mented.

Oversimplifying outrageously, we

state Brooks'

Law:

one-sixth or so of the problem, and

errors in its estimate or in the ratios

Adding

manpower to

late

software project makes

later.

could lead to ridiculous results.

Second, one must say that data for

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 ob-

solescence.) 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.

Calling

the

shot

How long will a system program-

ming job take? How much effort will

be required? How does one estimate?

I have earlier suggested ratios that

seem to apply to planning time, cod-

ing, component test, and system test.

First, one must say that one does

not

estimate the entire task

estimating

the coding portion only and then ap-

plying the ratios. The coding is only

building isolated small programs are

not applicable to programming systems

products. For a program averaging

about 3,200 words, for example, Sack-

man, Erikson, and Grant report an

average code-plusdebug time of about

178

hours for a single programmer, a

figure which would extrapolate to give

an annual productivity of 35,800 state

ments per year.

program half that

size took less than one-fourth

long,

and extrapolated productivity is almost

80,000

statements per year.t1J. Plan-

ning, documentation, testing, system

integration, and training times must

added. The linear extrapolation of

such spring figures is meaningless.

Ex-

trapolation of times for the hundred-

yard dash shows that

man

can

run a

mile in under three minutes.

Before dismissing them, however, let

us note that these numbers, although

not for strictly comparable problems,

suggest that effort goes as a power of

size

even

when no communication

involved except that of a man with his

memories.

Thousands of machine instructions

Fig.

As a project's complexity increases, the number of man-months required to

complete it goes up exponentially.

Fig.

tells the sad story. It illustrates

results reported from a study done by

Nanus and Farrl21 at System Develop-

ment Corp. This shows an exponent of

1.5;

that is,

effort

(constant)x(nuniber

instructions)l~~

Another

SDC

study reported by Wein-

wunnt31

also shows

exponent near

1.5.

A few studies on programmer pro-

ductivity have been nade, and several

Operational

Maintenance

Compiler

Translator

(Data assembler)

Prog.

units

Number of

programmers

estimating techniques have been pro-

posed. Morin has prepared a survey of

the published

data.[*] Here

shall

give only

few items that seem espe-

cially illuminating.

Portman's

data

Charles Portman, manager of

ICL'S

Software Div., Computer Equipment

Organization (Northwest) at Man-

chester, offers another useful personal

Words/

man-yr.

Table

Data from l3ell Labs indicates productivity differences between complex

problems (the first two are basically control programs with many modules) and less

complex ones. No ore is certain how much of the difference is due to complexity,

how much to the number of people involved.

Mar Jun Sep Dec Mar Jun Sep Dec

Fig.

Bell Labs' expt rience

predicting programming effort on one project.

insight.

He found his programming teams

missing schedules by about

one-half-

each job was taking approximately

twice as long as estimated. The esti-

mates were very careful, done by ex-

perienced teams estimating man-hours

for several hundred

subtasks on a

PERT

chart. When the slippage pattern ap-

peared, he asked them to keep careful

daily logs of time usage. These showed

that the estimating error could be en-

tirely accounted for by the fact that

his

teams were only realizing 50% of the

working week as actual programming

and debugging time. Machine down-

time, higher-priority short unrelated

jobs, meetings, paperwork, company

business, sickness, personal time, etc.

accounted for the rest. In short, the

estimates made an unrealistic assump-

tion about the number Of technical

work hours per man-year. My own

experience quite confirms

his

conclu-

sion.

An unpublished

1964

study by

Bardaii shows programmers realizing

only 27% productive time.161

Aron's

data

Joel Aron, manager of Systems

Technology at

IBM

in Gaithersburg,

Maryland, has studied programmer

productivity when working on nine

large systems (briefly,

large

means

more than

programmers and 30,-

000

deliverable instructions). He di-

vides such systems according to inter-

actions among programmers (and sys-

tern parts) and finds productivities as

follows

Very

few

interactions

10000

instructions per man-year

Some interactions

5,000

Many interactions

1,500

The man-years do not include sup*

port and system test activities, only

design and programming. When these

figures are diluted by a factor

two

cover system test, they closely match

Harr's data.

Hair's

data

John Harr, manager of program-

(/)

ming for the Bell Telephone Labora-

tories' Electronic Switching System,

reported his and others' experience in a

paper at the

1969

Spring Joint Com-

puter Conference.[*] These data are

shown in Table

and Figs.

and 7

Of these, Fig.

is the most detailed

and the most useful. The first two

jobs

are basically control programsethe sec-

ond two are basically language transla-

tors. Productivity

stated in terms of

debugged words per man-year. This in-

cludes programming, component test,

Mar Jun Sep Dec Mar

Jun

sep

and system test. It is not clear how

Fig.

Bell's predictions for debugging rates on a single project, contrasted with

much of the planning effort, or effort

actual figures.

in machine support, writing, and the

like, is included.

The productivities likewise fall into

two

classifications:

those

for control

programs are about

600

words per

man-year; those for translators are

about

2,200

words per man-year. Note

that all four programs are of similar

size-the variation is in size of the

work groups, length of time, and num-

ber of modules. Which is cause and

which is effect? Did the control pro-

grams require more people because

they were more complicated? Or did

they require more modules and more

man-months because they were as-

signed more people? Did they take

longer because of thi; greater complex-

ity, or because more people were as-

signed? One can't be sure. The control

programs were surely more complex.

These uncertainties aside, the num-

bers describe the real productivities

achieved on a large 5ystem. using pres-

ent-day programming techniques. As

such they are a real contribution.

Figs. 6 and

show some interesting

data on programming and debugging

rates as compared to predicted rates.

OSl360

data

IBM

os/360 experience, while not

available in the detail of Harr's data,

confirms it. Product ivities in range of

600-800

debugged instructions per

man-year were experienced by control

program groups. Productivities in the

2,000-3,000 debugged instructions per

man-year were achieved by language

translator groups. Tliese include plan-

ning done by the gr,~up, coding com-

ponent test, system test, and some sup-

port activities. They ,ire comparable to

Harr's data, so far as

can tell.

Aron's data, Hanm's data, and the

0~1360 data all confirm striking differ-

ences in productivity related to the

complexity and difficulty of the task

itself. My guideline in the morass of

estimating complexity is that compilers

are three times

bail

normal batch

application programs, and operating

systems are three times as bad

com-

pilers.

Corbato's data

Both Harr's data

and os/360 data

are for assembly language program-

ming. Little data seem to have been

published on system programming

productivity using higher-level lan-

guages. Corbat6 of

MIT'S

Project

MAC

reports, however, a mean productivity

1,200

lines of debugged PL/I state-

ments per man-year on the

MULTICS

system (between 1 and

million

words)

I71

This number is very exciting. Like

the other projects,

MULTICS

includes

control programs and language transla-

tors. Like the others, it is producing a

system programming product, tested

and documented. The data seem to be

comparable in terms of kind of effort

included. And the productivity number

is a good average between the control

program and translator productivities

of other projects.

But Corbat6's number is lines per

man-year, not words! Each statement

his

system corresponds to about

three-to-five words of handwritten

code! This suggests two important con.

clusions

Productivity seems constant in terms

of elementary statements, a conclu-

sion that

reasonable in terms of

the thought a statement requires and

the errors it may include.

Programming productivity may be

increased

much as five times

when a suitable high-level language

is used. To back up these conclu-

sions, W.

Taliaffero also reports

a constant productivity of

2,400

statements/year

Assembler,

FOR-

TRAN,

and

COBOL.~

A. Nelson

has shown a 340-1 productivity im-

provement for high-level language,

although his standard deviations are

wide.Pl

Hatching a catastrophe

When one hears of disastrous sched-

ule slippage in a project, he imagines

that a series of major calamities must

have befallen it. Usually, however, the

disaster is due to termites, not torna-

does; and the schedule has slipped im-

perceptibly but inexorably. Indeed,

major calamities are easier to handle;

one responds with major force, radical

reorganization, the invention of new

approaches. The whole team rises to

the occasion.

But the day-byday slippage is hard-

er to recognize, harder to prevent,

harder to make up. Yesterday a key

man was sick, and a meeting couldn't

be held. Today the machines are all

down, because lightning struck the

building's power transformer. Tomor-

row the disc routines won't start test-

ing,

because the first disc is a week late

from

the

factory. Snow, jury duty,

family problems, emergency meetings

with customers, executive audits-the

list goes on and on. Each one only

postpones some activity by a

halfday

or a day. And the schedule slips, one

day at a time.

How does one control a big project

on a tight schedule? The first step is to

have

a schedule. Each of a list of

events, called milestones, has a date.

Picking the dates is an estimating prob-

lem, discussed already and crucially

dependent on experience.

For picking the milestones there is

only one relevant rule. Milestones

must

be concrete, specific, measurable

events, defined with knife-edge sharp-

ness. Coding, for a counterexample, is

"90% finished" for half of the total

coding time. Debugging is

"99%

com-

plete" most of the time. "Planning

complete" is an event one can proclaim

almost at

will.[l01

Concrete milestones, on the other

hand, are

100%

events. "Specifications

signed by architects and implement-

em," "source coding

100%

complete,

keypunched, entered into disc library,"

"debugged version passes all test

cases." These concrete milestones

de-

mark the vague phases of planning,

coding, debugging.

It is more important that milestones

be sharp-edged and unambiguous than

that they be easily verifiable by the

boss. Rarely will a man lie about mile-

None love

the

bearer of bad news.

Sophocles

stone progress,

the milestone is so

sharp that he can't deceive himself.

But if the milestone is fuzzy, the boss

often understands a different report

from that which the man gives. To

supplement Sophocles, no one enjoys

bearing bad news, either, so it gets

softened without any real intent to

de-

CL-

ceive.

Two interesting studies of estimating

behavior by government contractors

on large-scale development projects

show that:

Estimates of the length of an activ-

ity made and revised carefully

every two weeks before the activity

starts do not significantly change as

the start time draws near, no mat-

ter how wrong they ultimately turn

out to be.

During the activity, overestimates

duration come steadily down as

the activity proceeds.

Underestimates do not change sig-

nificantly during the activity until

about three weeks before the

scheduled completion.[11]

Sharp milestones are in fact a ser-

vice to the te&m, and one they can

properly expect from a manager. The

fuzzy milestone is the harder burden to

live with. It is in fact a millstone that

grinds down morale, for it deceives one

about lost time until it is irremedi-

able. And chronic schedule slippage is

morale-killer.

"The

other

piece

latew

A schedule slips a day; so what?

Who gets excited about a one-day slip?

We can make it up later. And the other

piece ours fits into is late anyway.

baseball manager recognizes a

nonphysical talent,

hustle,

es-

sential gift of greal players and great

teams. It is the chiiracteristic of, run-

ning faster than necessary, moving

sooner than necessary, trying harder

than necessary. It is essential for great

programming team:;, too. Hustle pro-

vides the cushion, the reserve capacity,

that enables a team to cope with rou-

tine mishaps, to ant cipate and forfend

minor calamities. The calculated re-

sponse, the measui ed effort, are the

wet blankets that dampen hustle. As

we have seen, one

must

get excited

about

one-day slip. Such are the ele-

ments of catastrophe.

But not all

one-dily slips are equally

disastrous. So some calculation of re-

sponse is necessary though hustle be

dampened. How does one tell which

slips matter? There is no substitute for

PERT

chart or a critical-path sched-

ule. Such a network shows who waits

for what. It shows who is on the criti-

cal path, where any slip moves the

end date. It also shaws how much an

activity can slip

bei'ore it moves into

the critical path.

The

PERT

technique, strictly speak-

ing, is an elaboration of critical-path

scheduling in which one estimates

three times for every event, times cor-

responding to different probabilities of

meeting the estimated dates. I do not

find this refinement to be worth the

extra effort, but for brevity I will call

any critical path network a

PERT

chart.

The preparation of a

PERT

chart is

the most valuable part of its use. Lay-

ing out the network, identifying the

dependencies, and estimating the legs

all force a great deal of very specific

planning very early in a project. The

first chart is always terrible, and one

invents and invents in making the sec-

ond one.

As the project proceeds, the

PERT

chart provides the answer to the de-

moralizing excuse, "The other piece is

late anyhow." It shows how hustle is

needed to keep one's own part off the

critical path, and it suggests ways to

make up the lost time in the other

part.

Under the rug

When a first-line manager sees his

small team slipping behind, he is rarely

inclined to run to the boss with this

woe. The team might be able to make

it up, or he should be able to invent or

reorganize to solve the problem. Then

why worry the boss with it?

far, so

good. Solving such problems is exactly

what the first-line manager is there

for. And the boss does have enough

real worries demanding his action that

SYSTEM/360 SUMMARY STATUS REPORT

05/369 LANGUAGE PROCESSORS

SERVICE PROGRAMS

AS OF FEBRUARY 01

1965

C MMITMNT OBJECTIVE SPECS

ANNOUNCE AVAI

BLE

AVAILABLE

PROJECT LOCATION RELEASE APPROVED APPROVED

OPERATING SYSTEM

12K DESIGN LEVEL (E)

ASSEMBLY SAN JOSE 04/--/4 10/28/4 C 10/13/4

12/31/5 01/11/5

FORTRAN POK 04/--/4 C 10/28/4 C 10/21/4 C

12/31/5 01/22/5

COBOL ENDICOTT 04/--/4 C 10/25/4 C 10/15/4 C

12/31/5 01/20/5 A

RPG SAN JOSE 04/--/4

10/28/4

09/30/4 C

12/31/5 01/05/5 A

UTILITIES TIMWLIFE 04/--/4 C 06/24/4 C

12/31/5

SORT 1 POK 04/--/4 C 10/28/4 C 10/19/4 C

12/31/5 01/11/5

SORT 2 POK 04/--/4 C 10/28/4 C 10/19/4 C

06/30/6 01/11/5

44K DESIGN LEVEL (F)

ASSEMBLY SAN JOSE 04/--/4

10/28/4 C 10/13/4 C

12/31/5 01/11/5

COBOL TIMWLIFE 04/--/4 C 10/28/4 C 10/15/4 C

06/30/6 01/20/5

NPL HURSLEY 04/--/4 C 10/28/4 C

03/31/6

2250 KINGSTON 03/30/4 C 11/05/4 C 10/06/4 C

03/31/6 01/04/5

2280 KINGSTON 06/30/4 C 11/05/4 C

09/30/6

200K DESIGN LEVEL (HI

ASSEMBLY TIMWLIFE 10/28/4 C

FORTRAN POK

04/--/4 C 10/28/4

10/16/4 C

06/30/6 01/11/5

NPL HURSLEY

04/--/4 C 10/28/4 C

NPL

POK

041--14 C 03/30/4 C

Fig.

report showing milestones and status in a key docu-

ment in project control. This one shows some problems in

development: specifications approval is late on some items

he doesn't seek others.

all the dirt

gets swept under the rug.

But every boss needs two kinds of

information, exceptions for action and

a status picture for education.[12] For

that purpose he needs to know the

status of all his teams. Getting a true

picture of that status is hard.

The first-line manager's interests

and those of the boss have an inherent

conflict here. The first-line manager

fears that if he reports his problem,

the boss will act on it. Then his action

will preempt the manager's function,

diminish his authority, foul up his

other plans. So as long as the man-

ager thinks he can

solve,it alone, he

doesn't tell the boss.

Two rug-lifting techniques are open

to the boss. Both must be used. The

first is to reduce the role conflict and

inspire sharing of status. The other is

to yank the rug back.

Reducing the role conflict

The boss must first distinguish be-

tween action information and status

information. He must discipline him-

self

not

to act on problems his manag-

ers can solve, and

never

to act on

problems when he is explicitly review-

ing status. I once knew a boss who

invariably picked up the phone to give

orders before the end of the first para-

REVISED PLANNED DATE

NE=NOT ESTABLISHED

SRL ALPHA TEST COMP TEST SYS TEST BULLETIN BETA TEST

AVAILABLE ENTRY

START START

AVAILABLE ENTRY

APPROVED EXIT

COMPLETE COMPLETE

APPROVED EXIT

11/11/4 C 02/15/5 03/01/6

12/10/4 A 03/22/5 05/30/6

07/--/5 01/--/7

02/01/5 10/15/5

04/01/5 12/15/5

(those without

"A");

documentation

(SRL)

approval

overdue

on another; and one

(2250

support)

late coming out of

alpha test.

graph in a status report. That response

guaranteed to squelch full disclosure.

Conversely, when the manager

knows his boss will accept status re-

ports

without panic or preemption, he

comes to give honest appraisals.

This whole process is helped if the

boss

labels meetings, reviews, confer-

ences, as

status-review

meetings versus

problem-action

meetings, and controls

himself accordingly. Obviously one

may call a problem-action meeting as a

consequence of a status meeting, if he

believes a problem is out of hand. But

at least everybody knows what the

score is. and the boss thinks twice

be-

fore grabbing th

ball.

Yanking

the

nig

off

Nevertheless, it is necessary to have

review techniques by which the true

status is made known, whether cooper-

atively or not. The

PERT

chart with its

frequent sharp milestones is the basis

for such review. On a large project one

may want to review some part of it

each week, making the rounds once a

month or so.

report showing milestones and ac-

tual

completions is the key document.

Fig.

(precedini; page), shows an ex-

cerpt from such a report. This report

shows some troutiles. Specifications ap-

proval

overdue on several corn$

nents. Manual

(SRL)

approval is over-

due on another, ind one is late getting

out of the first

jtate

(ALPHA)

of the

independently co iducted product test.

such a report serves as an agenda

for

the

meeting of

February. Every-

one

knows the questions, and the com-

ponent manager should

prepared

explain why it's ate, when it will

finished, what strps he's taking, and

what help, if any, he needs from the

boss

or collateral groups.

V. Vyssotsky of Bell Telephone

Laboratories adds the following obser-

vation:

have found it handy to carry both

"scheduled" and 'estimated" dates in

the milestone retort. The scheduled

dates are the property of the project

manager and represent a consistent

work plan for the project

a whole,

and

one which is

priori

a reasonable

plan.

The estimate~i dates are the prop-

erty

the lowest level manager who

has

cognizance

over

the piece of work

question, and represents his best

judgment as to when

will actually

happen, given

thr resources he has

available and when he received (or has

commitments for delivery of) his pre-

requisite inputs. The project manager

has

to keep his fingers off the estimated

dates, and put the tmphasis on getting

accurate, unbiased estimates rather

than palatable optimistic estimates or

self-protective conservative ones. Once

this is clearly established in everyone's

mind, the project manager can see

quite

ways into the future where he is

going to be in trouble if he doesn't do

something.

The preparation of the

PERT

chart is

a function of the boss and the manag-

ers reporting to him. Its updating, revi-

sion, and reporting requires the atten-

tion of a small (one-to-three-man)

staff group which serves as an exten-

sion of the boss. Such a "Plans and

Controls" team is invaluable for a large

project. It has no authority except to

ask all the line managers when they

will have set or changed milestones,

and whether milestones have been met.

Since the Plans and Controls group

handles all the paperwork, the burden

on the line managers is reduced to the

essentials-making the decisions.

We had a skilled, enthusiastic, and

diplomatic Plans and Controls group

on the

os/360

project, run by A.

Pietrasanta, who devoted considerable

inventive talent to devising effective

but unobtrusive control methods. As

a result, I found his group to

widely

respected and more than tolerated. For

a group whose role is inherently that

of an irritant, this is quite an accom-

plishment.

The investment of a modest amount

of skilled effort in a Plans and Controls

function is very rewarding. It makes

far more difference in project accom-

plishment than if these people worked

directly on building the product pro-

grams. For the Plans and Controls

group is the watchdog who renders the

imperceptible delays visible and' who

points up the.critical elements. It is the

early'warning system against losing a

year, one day at a time.

Epilogue

The tar pit of software engineering

will continue to be sticky for a long

time

come. One can expect the hu-

man race to continue attempting sys-

tems just within or just beyond our

reach; and software systems are per-

haps the most intricate and comvlex of

man's handiworks. The management

of this complex craft will demand our

best use of new languages and systems,

our best adaptation of proven engi-

neering management methods, liberal

doses of common sense, and a

God-

given humility to recognize our fallibil-

ity and limitations.

References

Sacknm,

H.,

Erikson, and

E. Grant,

"Exploratory Experimentation Studies Com-

paring Online and Offline Programming

Per-

fonnance."

Communications of the ACM,

(1968). 3-11.

Nanus, B., and L.

Farr,

"Some

Cost Contrite

utors to Large-Sole-Programs,"

AFIPS

Pro-

ceedinga, SJCC,

(1964),

239-248.

Weinwurm,

F.,

Research

the Mana#e-

ment of Computer Programmiw.

Report SP-

2059, 1965,

System Development Corp.,

Santa

Monica.

Morin,

H.,

Estimation of Resources for

Computer Programming Projects,

S. thesis,

Univ. of North Carolina, Chapel Hill,

1974.

Quoted by D. B. Mayer and A. W. Stalnaker.

Â¥"Selectio and Evaluation of Computer Per-

sonnel,"

Proceedings

ACM Conference,

1968.661.

Paper given at a panel session and not in-

cluded in the

AFIPS

Proceedings.

Corbat6.

I.,

Sensitive Issues in the Desitn

of Multi-Use Systems.

Lecture at the opening

of the Honeywell

EDP

Technology Center,

1968.

Taliaffcro, W.

M..

"Modularity the

Key

System Growth Potential,"

Software,

(1971).

245-257.

Nelson, E. A.,

Management Handbook for the

Estimation of Computei Protramming Costs.

Report

TM-3225,

System Development

Corp.,

Santa Monica,

pp.

66-67.

10.

Reynolds,

H.. "What's Wrong with

Com-

outer Programming Management?"

On the

Management of Computer Programming.

Ed.

Weinwurm. Philadelphia: Auerbtch.

1971,

pp.

3542.

11.

King, W. R., and

Wilson, "Subjective

Time

Estimates

Critical Path Planning4

Preliminary Analyw'

Management Sciences,

13 (1967). 307-320,

and

sequel, W.

King,

Witterrongel. and

D. Hezel,

"On

the Analysis of Critical Path Time &timating

Behavior,"

Management Sciences,

14 (1967).

79-84,

12.

Brooks,

F. P.,

and

Ivenon.

Automatic

Data Processing, System/SSO ~dition.

New

York: Wiley,

1969,

pp.

428-430.

Or. Brooks is presently a professor

at the Univ. of North Carolina at

Chapel Hill, and chairman

the

computer science department

there.

is best known as "the

father

the

IBM Systeml360,~'

having served as project manager

for

the

hardware development and

as manager

the Operating Sys-

tam1360 project during its design

phase. Earlier he was an architect

of the IBM Stretch

and

Harvest

computers.

At Chapel Hill he has participated

in establishing and guiding

the

Tri-

angle Universities Computation

Center

and

the

North

Carolina Edu-

cational Computing Service.

the author of two editions

"Auto-

matic Data Processing" and

"The

Mythical Man-Month: Essays on

Software Engineering" (Addison-

Wesley), from which this excerpt is

taken.

This essay is part of a collection of essays published in 1975 by Brooks entitled *The Mythical Man-Month: Essays on Software Engineering*. The book has become one of the most cited works in Software Engineering and to this day, almost 50 years after publishing, it's still required reading in a lot of college courses on Software Engineering. The idea for writing the book originated from a question that Tom Watson, Jr (CEO of IBM) asked Fred Brooks in an exit interview: “Why is managing software harder than managing hardware development?". Brooks replied: "That's a hard question. I'll go home and think about it." - as a result of that reflection, he wrote *The Mythical Man-Month*. ![](https://i.imgur.com/YQd3SI0.jpg) Fred Brooks (born in 1931) is an American computer scientist. Brooks earned a Physics degree from Duke University and then joined the newly created degree in computer science at Harvard University where he earned a PhD in 1956. At Harvard he was a student of Howard Aiken, who during WWII developed the Harvard Mark I, the first automatic digital calculator built in the United States. After graduation Brooks was recruited by IBM. There he would eventually manage the development of OS/360 , the operating system of IBM System/360, a family of mainframe computers introduced in 1964. The Mythical Man-Month describes a lot of the lessons Brooks learned during this project, which was perhaps the largest operating system project of its time. ![](https://i.imgur.com/WOecNKz.jpg) *Fred Brooks* Victor Vyssotsky was a mathematician and computer scientist. He was a technical head of the Multics project at Bell Labs. Multics, would go on to heavily influence virtually all modern operating systems - Ken Thompson was directly inspired by it to develop Unix. According to a McKinsey-Oxford study, 1/3 of all large software projects (defined as those with initial budgets exceeding $15M) are delivered late ([full study](https://www.mckinsey.com/~/media/McKinsey/dotcom/client_service/BTO/PDF/MOBT_27_Delivering_large-scale_IT_projects_on_time_budget_and_value.ashx)). ![](https://i.imgur.com/zisCf6K.png) PERT stands for Program Evaluation and Review Technique. It provides a visual representation of a project's timeline and breaks down individual tasks. ![](https://i.imgur.com/2dItaFl.png) This is one of the cornerstones of modern software development methodologies such as Agile development. The formula $\frac{n(n-1)}{2}$ represents the number of all possible distinct pairs in a set of $n$ elements.

Comments

Products

Project