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
is
anextract from
the
Mythical Man-Month
by Frederick
P.
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
in
Datamation,
December 1974, pages 44-52.
NO
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
A
PROJECT GET TO
BEAYEAR
LATE?
.
. .
. .
.
ONE DAY AT A TIME.
By Frederick
P.
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
in
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-
ly
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
"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 take only
as
long
as
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
of
the
Maker,
divides creative activity into
three stages: the idea, the implementa-
tion, and the interaction.
A
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,
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 cre-
ative activity but also the Christian
doctrine of the Trinity, will help us
in
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-
um
of execution
is
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
as
a unit
for measuring the size
of
a
job
is
a
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.
1
)
.
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.
1.
The term "man-month" implies
that if one man takes
10
months to do a
job,
10
men can do it in one month. This
may
be
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)
/
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 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.
3.
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.
2.
Even on tasks that can
be
nicely
flexible representatlions thereof. Be-
In
tasks
that
an
be
partitioned
but
partitioned among people, the additional
cause the medium
is
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.
A
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
is
expressed in the very unit of effort
used in estimating and scheduling: the
man-month. Cost docs indeed vary as
work to
be
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,
so
this part of
the added effort varies linearly with the
number of workers.
V.
S.
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.
3.
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.
J.
rather than shorten, the schedule.