Essay preview
Essence and Accidents of
Software li eermng
Frederick P. Brooks, Jr.
University of North Carolina at Chapel Hill
Fashioning complex
conceptual constructs
is ,he
iS
the essence;
essence;
accidental tasks arise
in representing the
constructs in1
language. Past
progress has so
reduced the accidental
tasks that future
progress now depends
upon addressing the
essence.
f all the monsters that fill the
nightmares of our folklore, none
0 terrify more than werewolves,
because they transform unexpectedly
from the familiar into horrors. For these,
one seeks bullets of silver that can magic-
ally lay them to rest.
The familiar software project, at least as
by the nontechnical manager, has
something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver
bullet-something to make software costs
drop as rapidly as computer hardware
seen
costs do.
But, as
we
look to the horizon of
a
throughs-and indeed, I believe such to be
inconsistent with the nature of software-many encouraging innovations are under way. A disciplined, consistent effort
to develop, propagate, and exploit these
innovations should indeed yield an orderof-magnitude improvement. There is no royal road, but there is a road.
The first step toward the management
of disease was replacement of demon
theories and humours theories by the germ
theory. That very step, the beginning of
hope, in itself dashed all hopes of magical
solutions. It told workers that progress
would be made stepwise, at great effort,
and that a persistent, unremitting care
would have to be paid to a discipline of
cleanliness. So it is with software engi-
decade hence, we see no silver bullet. neering today.
There is no single development, in either
technology or in management technique,
that by itself promises even one order-of- Does it have to be magnitude improvement in productivity,
ad?E en_
in reliability, in simplicity. In this article, I hard?-Essent
shall try to show why, by examining both difficulties
the nature of the software problem and the
properties of the bullets proposed.
Skepticism is not pessimism, however.
Although we see no startling break-
Not only are there no silver bullets now
in view, the very nature of software makes
it unlikely that there will be any-no inventions that will do for software prodThis article was first published in Infonnation Process- uctivity, reliability, and simplicity what ing '86, ISBN No. 0-444-70077-3, H.-J. Kugler, ed.,
Elsevier Science Publishers B.V. (North-Hollad) © electronics, transistors, and large-scale IFIP 1986.
integration did for computer hardware.
10
COMPUTER
We cannot expect ever to see twofold gains
every two years.
First, one must observe that the anomaly is not that software progress is so slow, but that computer hardware progress is so
fast. No other technology since civilization
began has seen six orders of magnitude in
performance-price gain in 30 years. In no
other technology can one choose to take
the gain in either improved performance
or in reduced costs. These gains flow from
the transformation of computer manufacture from an assembly industry into a process industry. Second, to see what rate of progress one
can expect in software technology, let us
examine the difficulties of that technology. Following Aristotle, I divide them into essence, the difficulties inherent in the
nature of software, and accidents, those
difficulties that today attend its production but are not inherent. The essence of a software entity is a construct of interlocking concepts: data sets relationships among data items, algorithms, and invocations of functions. This essence is abstract in that such a conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed.
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not
the labor of representing it and testing the
fidelity of the representation. We still
make syntax errors, to be sure; but they
are fuzz compared with the conceptual
errors in most systems.
If this is true, building software will
always be hard. There is inherently no
silver bullet.
Let us consider the inherent properties
of this irreducible essence of modern software systems: complexity, conformity, changeability, and invisibility.
Complexity. Software entities are more
complex for their size than perhaps any
other human construct because no two
parts are alike (at least above the statement
level). If they are, we make the two similar
parts into a subroutine-open or closed.
In this respect, software systems differ
profoundly from computers, buildings, or
automobiles, where repeated elements
abound.
Digital computers are themselves more
complex than most things people build:
They have very large numbers of states.
This makes conceiving, describing, and
testing them hard. Software systems have
April 1987
orders-of-magnitude more states than
computers do.
Likewise, a scaling-up of a software entity is not merely a repetition of the same elements in larger sizes, it is necessarily an
increase in the number of different elements. In most cases, the elements interact with each other in some nonlinear fashion,
and the complexity of the whole increases
much more than linearly.
The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity
that abstract away its complexity often
abstract away its essence. For three centuries, mathematics and the physical sciences made great strides by constructing
simplified models of complex phenomena,
deriving properties from the models, and
verifying those properties by experiment,
This paradigm worked because the complexities ignored in the models were not the essential properties of the phenomena.
It does not work when the complexities are
the essence.
Many of the classic problems of developing software products derive from this essential complexity and its nonlinear increases with size. From the complexity comes the difficulty of conununication
among team members, which leads
to product flaws, cost overruns,
schedule delays. From the
complexity comes the
difficulty of enumerating, much less
understanding, all the possible states of
the program, and from that comes the
unreliability. From complexity of function
comes the difficulty of invoking function,
which makes programs hard to use. From
complexity of structure comes the difficulty of extending programs to new functions without creating side effects. From complexity of structure come the unvisualized states that constitute security
trapdoors.
Not only technical problems, but
management problems as well come from
the complexity. It makes overview hard,
thus impeding conceptual integrity. It
makes it hard to find and control all the
loose ends. It creates the tremendous
learning and understanding burden that
makes personnel turnover a disaster.
Conformity. Software people are not
alone in facing complexity. Physics deals
c
-
with terribly complex objects even at the
"fundamental" particle level. The physicist labors on, however, in a firm faith that there are unifying principles to be
found, whether in quarks or in unifiedfield theories. Einstein argued that there must be simplified explanations of nature,
because God is not capricious or arbitrary.
No such faith comforts the software engineer. Much of the complexity that he must master is arbitrary complexity,
forced without rhyme or reason by the
many human institutions and systems to
which his interfaces must conform. These
differ from interface to interface, and
from time to time, not because of necessity
but only because they were designed by
different people, rather than by God.
In many cases, the software must conform because it is the most recent arrival on the scene. In others, it must conform
because it is perceived as the most
conformable. But in all cases, much com-
new computers, then at least new disks,
new displays, new printers come along;
and the software must be conformed to its
new vehicles of opportunity.
In short, the software product is embedded in a cultural matrix of applications, users, laws, and machine vehicles. These
all change continually, and their changes
inexorably force change upon the software
product.
Invisibility. Software is invisible and unvisualizable. Geometric abstractions are powerful tools. The floor plan of a building helps both architect and client evaluate spaces, traffic flows, views. Contradictions and omissions become obvious.
Despite progress in
resctig and implifg
softnare stct s theyy
rmainihrently
remaM 'lnherntly
unVisualizable, and thus
plexitycomes from conformationtoother
interfaces; this complexity cannot be
simplified out by any redesign of the software alone.
do not permit the mind to
eof most
its
Changeability. The software entity is use someuseofsomitS
most
constantly subject to pressures for change. powerful conceptual tools. Of course, so are buildings, cars, computers. But manufactured things are infrequently changed after manufacture; they are superseded by later models, or essen- Scale drawings of mechanical parts and tial changes are incorporated into later- stick-figure models of molecules, alserial-number copies of the same basic though abstractions, serve the same pur-
design. Call-backs of automobiles are
really quite infrequent; field changes of
computers somewhat less so. Both are
much less frequent than modifications to
fielded software.
In part, this is so because the software of
a system embodies its function, and the
function is the part that most feels the
pressures of change. In part it is because
software can be changed more easily-it is
pure thought-stuff, infinitely malleable.
Buildings do in fact get changed, but the
high costs of change, understood by all,
serve to dampen the whims of the
changers.
All successful software gets changed.
Two processes are at work. First, as a software product is found to be useful, people try it in new cases at the edge of or beyond
the original domain. The pressures for extended function come chiefly from users who like the basic function andinvent new
uses for it.
Second, successful software survives
beyond the normal life of the machine
vehicle for which it is first written. If not
12
lack not only impedes the process of
design within one mind, it severely hinders
communication among minds.
Past
breakthroughs
solved accidental
difficulties
If we examine the three steps in soft-
ware-technology development that have
been most fruitful in the past, we discover
that each attacked a different major difty in build softwfrent majose ficulty in building software buta t
difficultiesh be antal, t
ntial dificultie
exca n o eech
ti
such_atual
High-level languages. Surely the most
powerful stroke for software productivity,
reliability, and simplicity has been the progressive use of high-level languages for programming. Most observers credit that
development with at least a factor of five
in productivity, and w...