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 sabertoothed tigers struggling against
the grip of the tar. The fiercer the struggle, the more entangling the
tar, and no beast is so strong or so skillful but that he ultimately
sinks.
Large-system programming has over the past decade been
such a tar pit, and many great and powerful beasts have thrashed
violently 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.
Therefore let us begin by identifying the craft of system programming
and the joys and woes inherent in it. (read more)
More software projects have gone awry for lack of calendar time
and the joys and woes inherent in it. (read more)
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 untrue,
i.e., that all will go well.
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 progress, hiding the assumption that men and months are
interchangeable.
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.
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.
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 requires
more gasoline, and thus begins a regenerative cycle which
ends in disaster.
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 disaster.
Schedule monitoring will be the subject of a separate essay.
Let us consider other aspects of the problem in more detail.
Let us consider other aspects of the problem in more detail.
