F. Brooks: No Silver Bullet—Essence and accident in software engineering (1986) 14
Therefore one of the most promising of the current technological efforts, and one
which attacks the essence, not the accidents, of the software problem, is the development
of approaches and tools for rapid prototyping of systems as part of the iterative
specification of requirements.
A prototype software system is one that simulates the important interfaces and
performs the main functions of the intended system, while not being necessarily bound by
the same hardware speed, size, or cost constraints. Prototypes typically perform the
mainline tasks of the application, but make no attempt to handle the exceptions, respond
correctly to invalid inputs, abort cleanly, etc. The purpose of the prototype is to make
real the conceptual structure specified, so that the client can test it for consistency and
Much of present-day software acquisition procedures rests upon the assumption that
one can specify a satisfactory system in advance, get bids for its construction, have it
built, and install it. I think this assumption is fundamentally wrong, and that many
software acquisition problems spring from that fallacy. Hence they cannot be fixed
without fundamental revision, one that provides for iterative development and
specification of prototypes and products.
Incremental development−grow, not build, software. I still remember the jolt I felt in
1958 when I first heard a friend talk about building a program, as opposed to writing one.
In a flash be broadened my whole view of the software process. The metaphor shift was
powerful, and accurate. Today we understand how like other building processes the
construction of software is, and we freely use other elements of the metaphor, such as
specifications, assembly of components, and scaffolding.
The building metaphor has outlived its usefulness. It is time to change again. If, as I
believe, the conceptual structures we construct today are too complicated to be accurately
specified in advance, and too complex to be built faultlessly, then we must take a
radically different approach.
Let us turn to nature and study complexity in living things, instead of just the dead
works of man. Here we find constructs whose complexities thrill us with awe. The brain
alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-
protecting, and self-renewing. The secret is that it is grown, not built.
So it must be with our software systems. Some years ago Harlan Mills proposed that
any software system should be grown by incremental development.
That is, the system
should first be made to run, even though it does nothing useful except call the proper set
of dummy subprograms. Then, bit-by-bit it is fleshed out, with the subprograms in turn
being developed into actions or calls to empty stubs in the level below.
I have seen the most dramatic results since I began urging this technique on the
project builders in my software engineering laboratory class. Nothing in the past decade
has so radically changed my own practice, or its effectiveness. The approach necessitates
top-down design, for it is a top-down growing of the software. It allows easy
backtracking. It lends itself to early prototypes. Each added function and new provision
for more complex data or circumstances grown organically out of what is already there.
Mills, H. D., “Top-down programming in large systems,” Debugging Techniques in Large Systems, R.
Rustin, ed., Englewood Cliffs, N.J., Prentice-Hall, 1971.