ArticlePDF Available

No Silver Bullet Essence and Accidents of Software Engineering


Abstract and Figures

First Page of the Article
Content may be subject to copyright.
No Silver Bullet: Essence and Accidents of
Software Engineering
by Frederick P. Brooks, Jr.
Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves,
because they transform unexpectedly from the familiar into horrors. For these, one seeks
bullets of silver that can magically lay them to rest.
The familiar software project, at least as seen 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 costs
But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single
development, in either technology or in management technique, that by itself promises even
one order-of-magnitude improvement in productivity, in reliability, in simplicity. In this
article, I shall try to show why, by examining both the nature of the software problem and the
properties of the bullets proposed.
Skepticism is not pessimism, however. Although we see no startling breakthroughs--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 order-of-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 engineering today.
Does It Have to Be Hard?--Essential Difficulties
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 productivity, reliability, and
simplicity what electronics, transistors, and large-scale integration did for computer hardware.
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
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
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 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
communication 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 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 complexity comes from conformation to other interfaces; this complexity cannot be
simplified out by any redesign of the software alone.
Changeability. The software entity is constantly subject to pressures for change. Of course,
so are buildings, cars, computers. But manufactured things are infrequently changed after
manufacture; they are superseded by later models, or essential changes are incorporated into
later-serial-number copies of the same basic 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 and
invent new uses for it.
Second, successful software survives beyond the normal life of the machine vehicle for which
it is first written. If not 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. Scale drawings of mechanical
parts and stick-figure models of molecules, although abstractions, serve the same purpose. A
geometric reality is captured in a geometric abstraction.
The reality of software is not inherently embedded in space. Hence, it has no ready geometric
representation in the way that land has maps, silicon chips have diagrams, computers have
connectivity schematics. As soon as we attempt to diagram software structure, we find it to
constitute not one, but several, general directed graphs superimposed one upon another. The
several graphs may represent the flow of control, the flow of data, patterns of dependency,
time sequence, name-space relationships. These graphs are usually not even planar, much less
hierarchical. Indeed, one of the ways of establishing conceptual control over such structure is
to enforce link cutting until one or more of the graphs becomes hierarchical. [1]
In spite of progress in restricting and simplifying the structures of software, they remain
inherently unvisualizable, and thus do not permit the mind to use some of its most powerful
conceptual tools. This 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 software technology development that have been most
fruitful in the past, we discover that each attacked a different major difficulty in building
software, but that those difficulties have been accidental, not essential, difficulties. We can
also see the natural limits to the extrapolation of each such attack.
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 with
concomitant gains in reliability, simplicity, and comprehensibility.
What does a high-level language accomplish? It frees a program from much of its accidental
complexity. An abstract program consists of conceptual constructs: operations, data types,
sequences, and communication. The concrete machine program is concerned with bits,
registers, conditions, branches, channels, disks, and such. To the extent that the high-level
language embodies the constructs one wants in the abstract program and avoids all lower
ones, it eliminates a whole level of complexity that was never inherent in the program at all.
The most a high-level language can do is to furnish all the constructs that the programmer
imagines in the abstract program. To be sure, the level of our thinking about data structures,
data types, and operations is steadily rising, but at an ever decreasing rate. And language
development approaches closer and closer to the sophistication of users.
Moreover, at some point the elaboration of a high-level language creates a tool-mastery
burden that increases, not reduces, the intellectual task of the user who rarely uses the esoteric
Time-sharing. Time-sharing brought a major improvement in the productivity of
programmers and in the quality of their product, although not so large as that brought by high-
level languages.
Time-sharing attacks a quite different difficulty. Time-sharing preserves immediacy, and
hence enables one to maintain an overview of complexity. The slow turnaround of batch
programming means that one inevitably forgets the minutiae, if not the very thrust, of what
one was thinking when he stopped programming and called for compilation and execution.
This interruption is costly in time, for one must refresh one's memory. The most serious effect
may well be the decay of the grasp of all that is going on in a complex system.
Slow turnaround, like machine-language complexities, is an accidental rather than an essential
difficulty of the software process. The limits of the potential contribution of time-sharing
derive directly. The principal effect of timesharing is to shorten system response time. As this
response time goes to zero, at some point it passes the human threshold of noticeability, about
100 milliseconds. Beyond that threshold, no benefits are to be expected.
Unified programming environments. Unix and Interlisp, the first integrated programming
environments to come into widespread use, seem to have improved productivity by integral
factors. Why?
They attack the accidental difficulties that result from using individual programs together, by
providing integrated libraries, unified file formats, and pipes and filters. As a result,
conceptual structures that in principle could always call, feed, and use one another can indeed
easily do so in practice.
This breakthrough in turn stimulated the development of whole toolbenches, since each new
tool could be applied to any programs that used the standard formats.
Because of these successes, environments are the subject of much of today's software-
engineering research. We look at their promise and limitations in the next section.
Hopes for the Silver
Now let us consider the technical developments that are most often advanced as potential
silver bullets. What problems do they address--the problems of essence, or the remaining
accidental difficulties? Do they offer revolutionary advances, or incremental ones?
Ada and other high-level language advances. One of the most touted recent developments
is Ada, a general-purpose high-level language of the 1980's. Ada not only reflects
evolutionary improvements in language concepts, but indeed embodies features to encourage
modern design and modularization. Perhaps the Ada philosophy is more of an advance than
the Ada language, for it is the philosophy of modularization, of abstract data types, of
hierarchical structuring. Ada is over-rich, a natural result of the process by which
requirements were laid on its design. That is not fatal, for subsetted working vocabularies can
solve the learning problem, and hardware advances will give us the cheap MIPS to pay for the
compiling costs. Advancing the structuring of software systems is indeed a very good use for
the increased MIPS our dollars will buy. Operating systems, loudly decried in the 1960's for
their memory and cycle costs, have proved to be an excellent form in which to use some of
the MIPS and cheap memory bytes of the past hardware surge.
Nevertheless, Ada will not prove to be the silver bullet that slays the software productivity
monster. It is, after all, just another high-level language, and the biggest payoff from such
languages came from the first transition -- the transition up from the accidental complexities
of the machine into the more abstract statement of step-by-step solutions. Once those
accidents have been removed, the remaining ones will be smaller, and the payoff from their
removal will surely be less.
I predict that a decade from now, when the effectiveness of Ada is assessed, it will be seen to
have made a substantial difference, but not because of any particular language feature, nor
indeed because of all of them combined. Neither will the new Ada environments prove to be
the cause of the improvements. Ada's greatest contribution will be that switching to it
occasioned training programmers in modern software-design techniques.
Object-oriented programming. Many students of the art hold out more hope for object-
oriented programming than for any of the other technical fads of the day. [2] I am among
them. Mark Sherman of Dartmouth notes on CSnet News that one must be careful to
distinguish two separate ideas that go under that name: abstract data types and hierarchical
types. The concept of the abstract data type is that an object's type should be defined by a
name, a set of proper values, and a set of proper operations rather than by its storage structure,
which should be hidden. Examples are Ada packages (with private types) and Modula's
Hierarchical types, such as Simula-67's classes, allow one to define general interfaces that can
be further refined by providing subordinate types. The two concepts are orthogonal_one may
have hierarchies without hiding and hiding without hierarchies. Both concepts represent real
advances in the art of building software.
Each removes yet another accidental difficulty from the process, allowing the designer to
express the essence of the design without having to express large amounts of syntactic
material that add no information content. For both abstract types and hierarchical types, the
result is to remove a higher-order kind of accidental difficulty and allow a higher-order
expression of design.
Nevertheless, such advances can do no more than to remove all the accidental difficulties
from the expression of the design. The complexity of the design itself is essential, and such
attacks make no change whatever in that. An order-of-magnitude gain can be made by object-
oriented programming only if the unnecessary type-specification underbrush still in our
programming language is itself nine-tenths of the work involved in designing a program
product. I doubt it.
Artificial intelligence. Many people expect advances in artificial intelligence to provide the
revolutionary breakthrough that will give order-of-magnitude gains in software productivity
and quality. [3] I do not. To see why, we must dissect what is meant by "artificial
D.L. Parnas has clarified the terminological chaos: [4]
Two quite different definitions of AI are in common use today. AI-1: The use
of computers to solve problems that previously could only be solved by
applying human intelligence. Al-2: The use of a specific set of programming
techniques known as heuristic or rule-based programming. In this approach
human experts are studied to determine what heuristics or rules of thumb they
use in solving problems.... The program is designed to solve a problem the way
that humans seem to solve it.
The first definition has a sliding meaning.... Something can fit the definition of
Al-1 today but, once we see how the program works and understand the
problem, we will not think of it as Al any more.... Unfortunately I cannot
identify a body of technology that is unique to this field.... Most of the work is
problem-specific, and some abstraction or creativity is required to see how to
transfer it.
I agree completely with this critique. The techniques used for speech recognition seem to have
little in common with those used for image recognition, and both are different from those used
in expert systems. I have a hard time seeing how image recognition, for example, will make
any appreciable difference in programming practice. The same problem is true of speech
recognition. The hard thing about building software is deciding what one wants to say, not
saying it. No facilitation of expression can give more than marginal gains.
Expert-systems technology, AI-2, deserves a section of its own.
Expert systems. The most advanced part of the artificial intelligence art, and the most widely
applied, is the technology for building expert systems. Many software scientists are hard at
work applying this technology to the software-building environment. [3, 5] What is the
concept, and what are the prospects?
An expert system is a program that contains a generalized inference engine and a rule base,
takes input data and assumptions, explores the inferences derivable from the rule base, yields
conclusions and advice, and offers to explain its results by retracing its reasoning for the user.
The inference engines typically can deal with fuzzy or probabilistic data and rules, in addition
to purely deterministic logic.
Such systems offer some clear advantages over programmed algorithms designed for arriving
at the same solutions to the same problems:
Inference-engine technology is developed in an application-independent way, and then
applied to many uses. One can justify much effort on the inference engines. Indeed,
that technology is well advanced.
The changeable parts of the application-peculiar materials are encoded in the rule base
in a uniform fashion, and tools are provided for developing, changing, testing, and
documenting the rule base. This regularizes much of the complexity of the application
The power of such systems does not come from ever-fancier inference mechanisms but rather
from ever-richer knowledge bases that reflect the real world more accurately. I believe that
the most important advance offered by the technology is the separation of the application
complexity from the program itself.
How can this technology be applied to the software-engineering task? In many ways: Such
systems can suggest interface rules, advise on testing strategies, remember bug-type
frequencies, and offer optimization hints.
Consider an imaginary testing advisor, for example. In its most rudimentary form, the
diagnostic expert system is very like a pilot's checklist, just enumerating suggestions as to
possible causes of difficulty. As more and more system structure is embodied in the rule base,
and as the rule base takes more sophisticated account of the trouble symptoms reported, the
testing advisor becomes more and more particular in the hypotheses it generates and the tests
it recommends. Such an expert system may depart most radically from the conventional ones
in that its rule base should probably be hierarchically modularized in the same way the
corresponding software product is, so that as the product is modularly modified, the
diagnostic rule base can be modularly modified as well.
The work required to generate the diagnostic rules is work that would have to be done anyway
in generating the set of test cases for the modules and for the system. If it is done in a suitably
general manner, with both a uniform structure for rules and a good inference engine available,
it may actually reduce the total labor of generating bring-up test cases, and help as well with
lifelong maintenance and modification testing. In the same way, one can postulate other
advisors, probably many and probably simple, for the other parts of the software-construction
Many difficulties stand in the way of the early realization of useful expert-system advisors to
the program developer. A crucial part of our imaginary scenario is the development of easy
ways to get from program-structure specification to the automatic or semiautomatic
generation of diagnostic rules. Even more difficult and important is the twofold ,task of
knowledge acquisition: finding articulate, self-analytical experts who know why they do
things, and developing efficient techniques for extracting what they know and distilling it into
rule bases. The essential prerequisite for building an expert system is to have an expert.
The most powerful contribution by expert systems will surely be to put at the service of the
inexperienced programmer the experience and accumulated wisdom of the best programmers.
This is no small contribution. The gap between the best software engineering practice and the
average practice is very wide_perhaps wider than in any other engineering discipline. A tool
that disseminates good practice would be important.
"Automatic" programming. For almost 40 years, people have been anticipating and writing
about "automatic programming," or the generation of a program for solving a problem from a
statement of the problem specifications. Some today write as if they expect this technology to
provide the next breakthrough. [5]
Parnas [4] implies that the term is used for glamour, not for semantic content, asserting,
In short, automatic programming always has been a euphemism for
programming with a higher-level language than was presently available to the
He argues, in essence, that in most cases it is the solution method, not the problem, whose
specification has to be given.
One can find exceptions. The technique of building generators is very powerful, and it is
routinely used to good advantage in programs for sorting. Some systems for integrating
differential equations have also permitted direct specification of the problem, and the systems
have assessed the parameters, chosen from a library of methods of solution, and generated the
These applications have very favorable properties:
The problems are readily characterized by relatively few parameters.
There are many known methods of solution to provide a library of alternatives.
Extensive analysis has led to explicit rules for selecting solution techniques, given
problem parameters.
It is hard to see how such techniques generalize to the wider world of the ordinary software
system, where cases with such neat properties are the exception. It is hard even to imagine
how this breakthrough in generalization could occur.
Graphical programming. A favorite subject for PhD dissertations in software engineering is
graphical, or visual, programming--the application of computer graphics to software design.
[6, 7] Sometimes the promise held out by such an approach is postulated by analogy with
VLSI chip design, in which computer graphics plays so fruitful a role. Sometimes the theorist
justifies the approach by considering flowcharts as the ideal program-design medium and by
providing powerful facilities for constructing them.
Nothing even convincing, much less exciting, has yet emerged from such efforts. I am
persuaded that nothing will.
In the first place, as I have argued elsewhere [8], the flowchart is a very poor abstraction of
software structure. Indeed, it is best viewed as Burks, von Neumann, and Goldstine's attempt
to provide a desperately needed high-level control language for their proposed computer. In
the pitiful, multipage, connection-boxed form to which the flowchart has today been
elaborated, it has proved to be useless as a design tool--programmers draw flowcharts after,
not before, writing the programs they describe.
Second, the screens of today are too small, in pixels, to show both the scope and the
resolution of any seriously detailed software diagram. The so-called "desktop metaphor" of
today's workstation is instead an "airplane-seat" metaphor. Anyone who has shuffled a lap full
of papers while seated between two portly passengers will recognize the difference--one can
see only a very few things at once. The true desktop provides overview of, and random access
to, a score of pages. Moreover, when fits of creativity run strong, more than one programmer
or writer has been known to abandon the desktop for the more spacious floor. The hardware
technology will have to advance quite substantially before the scope of our scopes is
sufficient for the software-design task.
More fundamentally, as I have argued above, software is very difficult to visualize. Whether
one diagrams control flow, variable-scope nesting, variable cross references, dataflow,
hierarchical data structures, or whatever, one feels only one dimension of the intricately
interlocked software elephant. If one superimposes all the diagrams generated by the many
relevant views, it is difficult to extract any global overview. The VLSI analogy is
fundamentally misleading--a chip design is a layered two-dimensional description whose
geometry reflects its realization in 3-space. A software system is not.
Program verification. Much of the effort in modern programming goes into testing and the
repair of bugs. Is there perhaps a silver bullet to be found by eliminating the errors at the
source, in the system-design phase? Can both productivity and product reliability be radically
enhanced by following the profoundly different strategy of proving designs correct before the
immense effort is poured into implementing and testing them?
I do not believe we will find productivity magic here. Program verification is a very powerful
concept, and it will be very important for such things as secure operating-system kernels. The
technology does not promise, however, to save labor. Verifications are so much work that
only a few substantial programs have ever been verified.
Program verification does not mean error-proof programs. There is no magic here, either.
Mathematical proofs also can be faulty. So whereas verification might reduce the program-
testing load, it cannot eliminate it.
More seriously, even perfect program verification can only establish that a program meets its
specification. The hardest part of the software task is arriving at a complete and consistent
specification, and much of the essence of building a program is in fact the debugging of the
Environments and tools. How much more gain can be expected from the exploding
researches into better programming environments? One's instinctive reaction is that the big-
payoff problems-- hierarchical file systems, uniform file formats to make possible uniform
program interfaces, and generalized tools--were the first attacked, and have been solved.
Language-specific smart editors are developments not yet widely used in practice, but the
most they promise is freedom from syntactic errors and simple semantic errors.
Perhaps the biggest gain yet to be realized from programming environments is the use of
integrated database systems to keep track of the myriad details that must be recalled
accurately by the individual programmer and kept current for a group of collaborators on a
single system.
Surely this work is worthwhile, and surely it will bear some fruit in both productivity and
reliability. But by its very nature, the return from now on must be marginal.
Workstations. What gains are to be expected for the software art from the certain and rapid
increase in the power and memory capacity of the individual workstation? Well, how many
MIPS can one use fruitfully? The composition and editing of programs and documents is fully
supported by today's speeds. Compiling could stand a boost, but a factor of 10 in machine
speed would surely leave thinktime the dominant activity in the programmer's day. Indeed, it
appears to be so now.
More powerful workstations we surely welcome. Magical enhancements from them we
cannot expect.
Promising Attacks on the Conceptual Essence
Even though no technological breakthrough promises to give the sort of magical results with
which we are so familiar in the hardware area, there is both an abundance of good work going
on now, and the promise of steady, if unspectacular progress.
All of the technological attacks on the accidents of the software process are fundamentally
limited by the productivity equation:
If, as I believe, the conceptual components of the task are now taking most of the time, then
no amount of activity on the task components that are merely the expression of the concepts
can give large productivity gains.
Hence we must consider those attacks that address the essence of the software problem, the
formulation of these complex conceptual structures. Fortunately, some of these attacks are
very promising.
Buy versus build. The most radical possible solution for constructing software is not to
construct it at all.
Every day this becomes easier, as more and more vendors offer more and better software
products for a dizzying variety of applications. While we software engineers have labored on
production methodology, the personal-computer revolution has created not one, but many,
mass markets for software. Every newsstand carries monthly magazines, which sorted by
machine type, advertise and review dozens of products at prices from a few dollars to a few
hundred dollars. More specialized sources offer very powerful products for the workstation
and other Unix markets. Even software tools and environments can be bought off-the-shelf. I
have elsewhere proposed a marketplace for individual modules. [9]
Any such product is cheaper to buy than to build afresh. Even at a cost of one hundred
thousand dollars, a purchased piece of software is costing only about as much as one
programmeryear. And delivery is immediate! Immediate at least for products that really exist,
products whose developer can refer products to a happy user. Moreover, such products tend to
be much better documented and somewhat better maintained than home-grown software.
The development of the mass market is, I believe, the most profound long-run trend in
software engineering. The cost of software has always been development cost, not replication
cost. Sharing that cost among even a few users radically cuts the per-user cost. Another way
of looking at it is that the use of n copies of a software system effectively multiplies the
productivity of its developers by n. That is an enhancement of the productivity of the
discipline and of the nation.
The key issue, of course, is applicability. Can I use an available off-the-shelf package to
perform my task? A surprising thing has happened here. During the 1950's and 1960's, study
after study showed that users would not use off-the-shelf packages for payroll, inventory
control, accounts receivable, and so on. The requirements were too specialized, the case-to-
case variation too high. During the 1980's, we find such packages in high demand and
widespread use. What has changed?
Not the packages, really. They may be somewhat more generalized and somewhat more
customizable than formerly, but not much. Not the applications, either. If anything, the
business and scientific needs of today are more diverse and complicated than those of 20
years ago.
The big change has been in the hardware/software cost ratio. In 1960, the buyer of a two-
million dollar machine felt that he could afford $250,000 more for a customized payroll
program, one that slipped easily and nondisruptively into the computer-hostile social
environment. Today, the buyer of a $50,000 office machine cannot conceivably afford a
customized payroll program, so he adapts the payroll procedure to the packages available.
Computers are now so commonplace, if not yet so beloved, that the adaptations are accepted
as a matter of course.
There are dramatic exceptions to my argument that the generalization of software packages
has changed little over the years: electronic spreadsheets and simple database systems. These
powerful tools, so obvious in retrospect and yet so late in appearing, lend themselves to
myriad uses, some quite unorthodox. Articles and even books now abound on how to tackle
unexpected tasks with the spreadsheet. Large numbers of applications that would formerly
have been written as custom programs in Cobol or Report Program Generator are now
routinely done with these tools.
Many users now operate their own computers day in and day out on various applications
without ever writing a program. Indeed, many of these users cannot write new programs for
their machines, but they are nevertheless adept at solving new problems with them.
I believe the single most powerful software-productivity strategy for many organizations
today is to equip the computer-naive intellectual workers who are on the firing line with
personal computers and good generalized writing, drawing, file, and spreadsheet programs
and then to turn them loose. The same strategy, carried out with generalized mathematical and
statistical packages and some simple programming capabilities, will also work for hundreds of
laboratory scientists.
Requirements refinement and rapid prototyping. The hardest single part of building a
software system is deciding precisely what to build. No other part of the conceptual work is as
difficult as establishing the detailed technical requirements, including all the interfaces to
people, to machines, and to other software systems. No other part of the work so cripples the
resulting system if done wrong. No other part is more difficult to rectify later.
Therefore, the most important function that the software builder performs for the client is the
iterative extraction and refinement of the product requirements. For the truth is, the client
does not know what he wants. The client usually does not know what questions must be
answered, and he has almost never thought of the problem in the detail necessary for
specification. Even the simple answer_"Make the new software system work like our old
manual information-processing system"_is in fact too simple. One never wants exactly that.
Complex software systems are, moreover, things that act, that move, that work. The dynamics
of that action are hard to imagine. So in planning any software-design activity, it is necessary
to allow for an extensive iteration between the client and the designer as part of the system
I would go a step further and assert that it is really impossible for a client, even working with
a software engineer, to specify completely, precisely, and correctly the exact requirements of
a modern software product before trying some versions of the product.
Therefore, one of the most promising of the current technological efforts, and one that attacks
the essence, not the accidents, of the software problem, is the development of approaches and
tools for rapid prototyping of systems as prototyping is part of the iterative specification of
A prototype software system is one that simulates the important interfaces and performs the
main functions of the intended system, while not necessarily being 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 exceptional tasks, respond correctly to
invalid inputs, or abort cleanly. The purpose of the prototype is to make real the conceptual
structure specified, so that the client can test it for consistency and usability.
Much of present-day software-acquisition procedure 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--
revision that provides for iterative development and specification of prototypes and products.
Incremental development--grow, don't 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
he 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 specified accurately in
advance, and too complex to be built faultlessly, then we must take a radically different
Let us turn 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
selfrenewing. 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. [10] That is, the system
should first be made to run, even if it does nothing useful except call the proper set of dummy
subprograms. Then, bit by bit, it should be fleshed out, with the subprograms in turn being
developed--into actions or calls to empty stubs in the level below.
I have seen 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
grows organically out of what is already there.
The morale effects are startling. Enthusiasm jumps when there is a running system, even a
simple one. Efforts redouble when the first picture from a new graphics software system
appears on the screen, even if it is only a rectangle. One always has, at every stage in the
process, a working system. I find that teams can grow much more complex entities in four
months than they can build.
The same benefits can be realized on large projects as on my small ones. [11]
Great designers. The central question in how to improve the software art centers, as it always
has, on people.
We can get good designs by following good practices instead of poor ones. Good design
practices can be taught. Programmers are among the most intelligent part of the population, so
they can learn good practice. Hence, a major thrust in the United States is to promulgate good
modern practice. New curricula, new literature, new organizations such as the Software
Engineering Institute, all have come into being in order to raise the level of our practice from
poor to good. This is entirely proper.
Nevertheless, I do not believe we can make the next step upward in the same way. Whereas
the difference between poor conceptual designs and good ones may lie in the soundness of
design method, the difference between good designs and great ones surely does not. Great
designs come from great designers. Software construction is a creative process. Sound
methodology can empower and liberate the creative mind; it cannot inflame or inspire the
The differences are not minor--they are rather like the differences between Salieri and Mozart.
Study after study shows that the very best designers produce structures that are faster, smaller,
simpler, cleaner, and produced with less effort. [12] The differences between the great and the
average approach an order of magnitude.
A little retrospection shows that although many fine, useful software systems have been
designed by committees and built as part of multipart projects, those software systems that
have excited passionate fans are those that are the products of one or a few designing minds,
great designers. Consider Unix, APL, Pascal, Modula, the Smalltalk interface, even Fortran;
and contrast them with Cobol, PL/I, Algol, MVS/370, and MS-DOS. (See Table 1.)
Hence, although I strongly support the technology-transfer and curriculumdevelopment
efforts now under way, I think the most important single effort we can mount is to develop
ways to grow great designers.
No software organization can ignore this challenge. Good managers, scarce though they be,
are no scarcer than good designers. Great designers and great managers are both very rare.
Most organizations spend considerable effort in finding and cultivating the management
prospects; I know of none that spends equal effort in finding and developing the great
designers upon whom the technical excellence of the products will ultimately depend.
Table 1. Exciting Vs. Useful But Unexciting Software Products.
Exciting Products
Yes No
Unix Cobol
Pascal Algol
Modula MVS/370
Smalltalk MS-DOS
My first proposal is that each software organization must determine and proclaim that great
designers are as important to its success as great managers are, and that they can be expected
to be similarly nurtured and rewarded. Not only salary, but the perquisites of recognition--
office size, furnishings, personal technical equipment, travel funds, staff support--must be
fully equivalent.
How to grow great designers? Space does not permit a lengthy discussion, but some steps are
Systematically identify top designers as early as possible. The best are often not the
most experienced.
Assign a career mentor to be responsible for the development of the prospect, and
carefully keep a career file.
Devise and maintain a careerdevelopment plan for each prospect, including carefully
selected apprenticeships with top designers, episodes of advanced formal education,
and short courses, all interspersed with solo-design and technicalleadership
Provide opportunities for growing designers to interact with and stimulate each other.
I thank Gordon Bell, Bruce Buchanan, Rick Hayes-Roth, Robert Patrick, and, most especially,
David Parnas for their insights and stimulating ideas, and Rebekah Bierly for the technical
production of this article.
D.L. Parnas, "Designing Software for Ease of Extension and Contraction," IEEE
Transactions on Software Engineering, Vol. 5, No. 2, March 1979, pp. 128-38.
G. Booch, "Object-Oriented Design," Software Engineering with Ada, 1983, Menlo
Park, Calif.: Benjamin/ Cummings.
lEEE Transactions on Software Engineering (special issue on artificial intelligence
and software engineering), l. Mostow, guest ed., Vol. 11, No. 11, November 1985.
D.L. Parnas, "Software Aspects of Strategic Defense Systems:" American Scientist,
November 1985.
R. Balzer, "A 15-year Perspective on Automatic Programming," IEEE Transactions
on Software Engineering (special issue on artificial intelligence and software
engineering), J. Mostow, guest ed., Vol. 11, No. 11 (November 1985), pp. 1257-67.
Computer (special issue on visual programrning), R.B. Graphton and T. Ichikawa,
guest eds., Vol. 18, No. 8, August 1985.
G. Raeder, "A Survey of Current Graphical Programming Techniques," Computer
(special issue on visual programming), R.B. Graphton and T. Ichikawa, guest eds.,
Vol. 18, No. 8, August 1985, pp. 11-25.
F.P. Brooks, The Mythical Man Month, Reading, Mass.: Addison-Wesley, 1975,
Chapter 14.
Defense Science Board, Report of the Task Force on Military Software in press.
H.D. Mills, "Top-Down Programming in Large Systems," in Debugging Techniques in
Large Systems, R. Ruskin, ed., Englewood Cliffs, N.J.: Prentice-Hall, 1971.
B.W. Boehm, "A Spiral Model of Software Development and Enhancement," 1985,
TRW Technical Report 21-371-85, TRW, Inc., 1 Space Park, Redondo Beach, Calif.
H. Sackman, W.J. Erikson, and E.E. Grant, "Exploratory Experimental Studies
Comparing Online and Offline Programming Performance," Communications of the
ACM, Vol. 11, No. 1 (January 1968), pp. 3-11.
Brooks, Frederick P., "No Silver Bullet: Essence and Accidents of Software Engineering,"
Computer, Vol. 20, No. 4 (April 1987) pp. 10-19.
... In reviewing what has taken place in the history of software engineering, it is important to bear the context in mind. The concepts of Information Hiding (Parnas, 1972) and Abstract Data Types (Liskov and Zilles, 1974) were vital to the construction of systems by large groups of people, and came at a time when data was 'common' and goto statements were rife (Dijkstra, 1968 Brooks (1987) states that 'the complexity of software is an essential property, not an accidental one'. A solution to this essential complexity put forward by Brooks is the 'Build versus Buy' option where the economies of scale can allow vendors to increase the quality of their software by spreading the cost among multiple users. ...
... However, iteration must be managed to converge towards a solution, which can be assisted by making key decisions and recording any externalities early to reduce the solution space. Although methodologies and development frameworks have value, Brooks (1987) states that fostering great software designers will assist in addressing system complexity. However, processes often indicate documents and artefacts which aid the development and maintenance teams in understanding the project and decisions that have been made. ...
... The Internet and the World Wide Web have brought standards and protocols that can be targeted, with approaches such as RESTful interfaces becoming popular. Integrated Development Environments (IDEs) enable easy use of reusable libraries and classes, as predicted by Brooks (1987). Large, enterprise level software systems have been developed, with site-specific tailoring taking place after purchase (e.g. ...
... In a classic paper published in 1986 [8], Frederic Brooks Jr. described that a "usually innocent and straightforward" software project "is capable of becoming a monster of missed schedules, blown budgets, and flawed products." He then asserted, through detailed analysis, that there is no silver bullet for the software-project-turned monsters. ...
... The title of this paper is inspired by the presentation by M. Breidenbach and W. Barletta [7] and the paper by F. Brooks, Jr. [8]. We thank Vladimir Matias for providing ...
Full-text available
High-field superconducting magnets with a dipole field of 16 T and above enable future energy-frontier circular particle colliders. Although we believe these magnets can be built, none exists today. They can also be a showstopper for future high-energy machines due to a prohibitively high price tag based on the current conductor and magnet fabrication cost. The high-temperature superconducting REBCO coated conductor can address both the technical and cost issues, a silver bullet to lay both monsters to rest. The challenges and unknowns, however, can be too paramount to make the silver bullet. We lay out a potential road forward and suggest key action items. As a contribution from the accelerator community, we attempt to clarify for our theorist and experimenter colleagues a few aspects about the future high-field superconducting magnets. We hope to stimulate an effective plan for the 2023 P5 process that can lead to a cost-effective high-field magnet technology for future colliders and the exciting physics they can steward.
... -A completely different issue is the conceptual complexity of the software. This is what Brooks calls "essential complexity", and is what makes software development hard (Brooks 1987). Naturally it may also affect code comprehension studies. ...
Full-text available
Understanding program code is a complicated endeavor. As a result, studying code comprehension is also hard. The prevailing approach for such studies is to use controlled experiments, where the difference between treatments sheds light on factors which affect comprehension. But it is hard to conduct controlled experiments with human developers, and we also need to find a way to operationalize what “comprehension” actually means. In addition, myriad different factors can influence the outcome, and seemingly small nuances may be detrimental to the study’s validity. In order to promote the development and use of sound experimental methodology, we discuss both considerations which need to be applied and potential problems that might occur, with regard to the experimental subjects, the code they work on, the tasks they are asked to perform, and the metrics for their performance. A common thread is that decisions that were taken in an effort to avoid one threat to validity may pose a larger threat than the one they removed.
... Esta separación es bien clara porque suele no solo ser conceptual sino tecnológica, cuando el nivel de persistencia reside en un DBMS mientras que los niveles de la lógica y la presentación se programan en uno o más lenguajes de propósito general. Suscribiendo a la idea de que no hay ni habrá una bala de plata en la ingeniería de software [2], podemos conjeturar que las arquitecturas de múltiples niveles para las aplicaciones web, aunque es cierto que reportan muchos e importantes beneficios, simplemente podrían no ser la mejor solución en todos los casos. ...
Full-text available
Multi-tier architectures have been the de facto standard for web applications, leaving little room for alternative architectures. In the industry there is a product to develop and run web applications that follows a different architecture, centered on the RDBMS to the extreme of not needing any other component to function. There are not many papers in academia that addresses RDBMS-centric architectures in general, and this extreme architecture in particular has not been considered. In this work, the state of the art of database-centric architectures is analyzed, and an example of extreme database-centric architecture is analyzed. The general case of the architecture that I have called RDBMS-only is described, and the guidelines of this architecture are followed in the development of a functional prototype. Based on the implementation of that prototype, the feasibility of the architecture for a class of applications is shown, and a critical analysis of the architecture is carried out.
... The limiting issues are those which, as the word itself says, limit the extent to which gamification could have achieved a positive effect (Hyrynsalmi et al. 2017). Limiting factors, opposite to harmful, can be repaired with a relatively reasonable amount of work (Brooks 1987). Some of the noticed limitation issues in Meso-Cycle 3 are: ...
Full-text available
This dissertation addresses decreased academic participation, low engagement and poor experience as issues often related to students’ retention in online learning courses. The issues were identified at the Department of Computer Science at RWTH Aachen University, Germany, although high dropout rates are a growing problem in Computer Science studies worldwide. A solving approach often used in addressing the before mentioned problems includes gamification and personalization techniques: Gamification is a process of applying game design principles in serious contexts (i.e., learning), while personalization refers to tailoring the context to users’ needs and characteristics. In this work, the two techniques are used in combination in the Personalized Gamification Model (PeGaM), created for designing an online course for learning programming languages. PeGaM is theoretically grounded in the principles of the Gamified Learning Theory and the theory of learning tendencies. Learning tendencies define learners’ preferences for a particular form of behavior, and those behaviors are seen as possible moderators of gamification success. Moderators are a concept explained in the Gamified Learning Theory, and refer to variables that can influence the impact of gamification on the targeted outcomes. Gamification success is a measure of the extent to which students behave in a manner that leads to successful learning. The conceptual model of PeGaM is an iterative process in which learning tendencies are used to identify students who are believed to be prone to avoid certain activities. Gamification is then incorporated in activities that are recognized as ‘likely to be avoided’ to produce a specific learning-related behavior responsible for a particular learning outcome. PeGaM model includes five conceptual steps and 19 design principles required for gamification of learning environments that facilitate student engagement, participation and experience. In practice, PeGaM was applied in an introductory JavaScript course with Bachelor students of Computer Science at RWTH Aachen University. The investigation was guided by the principles of the Design-Based Research approach. Through this approach, PeGaM was created, evaluated and revised, over three iterative cycles. The first cycle had an explorative character, included one control and one treatment group, and gathered 124 participants. The second and third cycle were experimental studies, in which 69 and 171 participants were randomly distributed along one control and two treatment groups. Through the three interventions, mixed methods were used to capture students’ academic participation (a measure of students’ online behavior in the course collected through activity logs), engagement (evaluated quantitatively through a questionnaire compiled to measure behavioral, emotional, and cognitive engagement), and gameful experience (quantitative measure of students’ experience with the gamified system). In addition, supporting data was collected through semi-structured interviews and open-ended survey questions. The empirical findings revealed that gamification with PeGaM contributes to learning outcomes and that the success of gamification is conditioned by the applicability of game elements with learners’ preferences and learning activities. Cross case comparisons supported the application of PeGaM design principles and demonstrated its potential. Even though limited support was found to confirm the moderating role of learners’ learning tendencies, the study demonstrated that the gamification of learning activities that students are likely to avoid can increase their participation - but must be carefully designed. Most importantly, it has been shown that educational gamification can support and enhance learning-related behavior but require relevant and meaningful learning activities in combination with carefully considered reward, collaborative and feedback mechanisms. The study provides practical and theoretical insights but also highlights challenges and limitations associated with personalized gamification thus offers suggestions for further investigation.
... Results of an analysis of the Apache Software Foundation issue tracking show that developers do express emotion while discussing technical issues. Although these studies focus on a specific human aspect (i.e., emotion) from a developer's perspective, they indicate that a rational view of the software development process is insufficient; human aspects such as emotions can negatively or positively affect the development process and be propagated into the resulting software artefact, e.g., happiness, a positive emotion, increases creativity [69], which is good for a successful software design [70]. ...
Full-text available
Failure to consider the characteristics, limitations, and abilities of diverse end-users during mobile apps development may lead to problems for end-users such as accessibility and usability issues. We refer to this class of problems as human-centric issues. Despite their importance, there is a limited understanding of the types of human-centric issues that are encountered by end-users and taken into account by the developers of mobile apps. In this paper, we examine what human-centric issues end-users report through Google App Store reviews, which human-centric issues are a topic of discussion for developers on GitHub, and whether end-users and developers discuss the same human-centric issues. We then investigate whether an automated tool might help detect such human-centric issues and whether developers would find such a tool useful. To do this, we conducted an empirical study by extracting and manually analysing a random sample of 1,200 app reviews and 1,200 issue comments from 12 diverse projects that exist on both Google App Store and GitHub. Our analysis led to a taxonomy of human-centric issues that categorises human-centric issues into three-high levels: App Usage, Inclusiveness, and User Reaction. We then developed machine learning and deep learning models that are promising in automatically identifying and classifying human-centric issues from app reviews and developer discussions. A survey of mobile app developers shows that the automated detection of human-centric issues has practical applications. Guided by our findings, we highlight some implications and possible future work to further understand and incorporate human-centric issues in mobile apps development.
... Let us balance the concept of simplicity with the difference between essential and accidental complexity in software engineering 6 introduced by Frederick Phillips Brooks Jr., "There is no silver bullet" [104]. The essential complexity is a fundamental consequence of a problem's structure whereas the accidental complexity is a side effect coming from the implementation choice. ...
The Standard Model (SM) of particle physics was formulated theoretically during the twentieth century and completed in the 1970s. Since then, all particles predicted by this model have been observed experimentally. The latest discovery was the Higgs boson in 2012 and confirmed that the SM describes very well the world of elementary particles, at least when considering energies below 1 TeV. The anomalous magnetic dipole moment of the electron -- which is often credited as "the most accurate prediction in the history of physics" thanks to decades of very involved calculations -- was predicted up to ten significant digits by the SM. We know however that the SM is incomplete and cannot describe correctly elementary particle physics at higher energies, typically above 1 TeV. Studies Beyond the Standard Model (BSM) will become more and more important in the near future with the rapidly increasing amount of data from different experiments around the world. The full study of BSM models is in general an extremely time-consuming task involving long and difficult calculations. It is in practice not possible to do exhaustive predictions in these models by hand, in particular if one wants to perform a statistical comparison with data and the SM. To have the possibility to perform precise and systematic BSM analyses it is necessary to automate the associated theoretical predictions. As these calculations cannot be done numerically, we need a symbolic computer program able to calculate theoretical quantities from a general BSM Lagrangian that defines a particle physics model. Transition amplitudes, squared amplitudes and Wilson coefficients at tree-level and at one-loop must be derived from the Lagrangian in order to provide a general-purpose phenomenological tool that can predict observables in all domains of particle physics: Flavor physics, precision physics, Higgs physics, dark matter, ... We present how the calculations discussed above can be fully automated for general BSM scenarios through the presentation of MARTY -- the C++ framework that we developed to address this challenge -- that can become a very powerful tool for BSM phenomenology in all domains of particle physics. Through particular calculation examples which rely on a wide range of techniques we then present MARTY's ability to calculate amplitudes, squared amplitudes and Wilson coefficients in general BSM scenarios at the tree level and the one-loop level.
The introduction argues that the main purpose of this book is giving a rigorous definition of software from the point of view of continental philosophy. Continental philosophy can give us a new understanding of digital technology. This does not mean undermining the contribution of analytic philosophy or other disciplines. The book is halfway between two expanding fields of study: digital hermeneutics and critical code studies. Moreover, the introduction develops a historical analysis of software and explores the problem of defining what software is by comparing the theses of Kittler and Manovich.
In the face of increasingly agile product development, new challenges arise for assembly planning due to growing complexity. Within this paper, we show that the complexity-dependent combination of agile methods and traditionally plan-driven assembly planning procedures holds great potential for mastering planning complexity. Thus, a methodology towards hybrid assembly planning is elucidated with a focus on selecting dominant planning methods for specific planning scopes within this paper. Based on a detailed model of assembly planning as a system, the complexity requirements of different planning modules are determined. Therefore, an integrative complexity measure is developed to quantitatively operationalise complexity in a quasistatic-structural and a dynamic-functional complexity dimension. In order to identify dominant planning methods, the complexity potentials of agile and plan-driven methods are examined in an Analytic Hierarchy Process expert study with 22 participants. Within a decision model, dominant planning methods are selected for specific planning modules by matching the quantified complexity requirements with the complexity potentials of agile and plan-driven methods. Based on the systematic method selection, dominant planning methods for specific planning scopes can be tailored into a project-specific hybrid process framework. The approach to hybrid assembly planning enables optimised planning results through the improved mastery of complexity.
To let expressions evaluate to no or many objects, most object-oriented programming languages require the use of special constructs that encode these cases as single objects or values. While the requirement to treat these standard situations idiomatically seems to be broadly accepted, I argue that its alternative, letting expressions evaluate to any number of objects directly, has several advantages that make it worthy of consideration. As a proof of concept, I present a core object-oriented programming language, dubbed Num , which separates number from type so that the type of an expression is independent of the number of objects it may evaluate to, thus removing one major obstacle to using no, one, and many objects uniformly. Furthermore, Num abandons null references, replaces the nullability of reference types with the more general notion of countability, and allows methods to be invoked on any number of objects, including no object. To be able to adapt behavior to the actual number of receivers, Num complements instance methods with plural methods, that is, with methods which operate on a number of objects jointly, and which replace static methods known from other languages. An implementation of Num in Prolog and accompanying type and number safety proofs are presented.
Full-text available
A former member of the SDIO Panel on Computing in Support of Battle Management explains why he believes the “Star Wars” effort will not achieve its stated goals.
Full-text available
Designing software to be extensible and easily contracted is discussed as a special case of design for change. A number of ways that extension and contraction problems manifest themselves in current software are explained. Four steps in the design of software that is more flexible are then discussed. The most critical step is the design of a software structure called the " uses" relation. Some criteria for design decisions are given and illustrated using a small example. It is shown that the identification of minimal subsets and minimal extensions can lead to software that can be tailored to the needs of a broad variety of users.
The current software depression is characterized by software that is late, erroneous, and costly. Experience indicates that the application of appropriate design methodolgies, embodied in a high-order language, is appropriate in combatting this depression. In particular, this paper describes an object-oriented design methodology, using Ada as the implementation language.
This chapter describes a spiral model of software development and enhancement. The spiral model of the software process has been evolving for several years, based on experience with various refinements of the waterfall model as applied to large government software projects. The spiral model can accommodate most previous models as special cases and further provides guidance as to which combination of previous models best fits a given software situation. Development of the TRW Software Productivity System (TRW-SPS) is its most complete application to date. The chapter illustrates the radial dimension that represents the cumulative cost incurred in accomplishing the steps to date and the angular dimension that represents the progress made in completing each cycle of the spiral.
: Two exploratory experiments compared debugging performance of programers working under conditions of online and offline access to a computer. These are the first known studies measuring the performance of programers under controlled conditions for standard tasks. Statistically significant results indicated substantially faster debugging under online conditions in both studies. The results were ambiguous for central processor time--one study showed less computer time for debugging, and the other showed more time in the online mode. Perhaps the most important practical finding, overshadowing online/offline differences, involves the large and striking individual differences in programer performance. Attempts were made to relate observed individual differences to objective measures of programer experience and proficiency through factorial techniques. In line with the exploratory objectives of these studies, methodological problems encountered in designing and conducting these types of experiments are described, limitations of the findings are pointed out, hypotheses are presented to account for results, and suggestions are made for further research.
Designing software to be extensible and easily contracted is discussed as a special case of design for change. A number of ways that extension and contraction problems manifest themselves in current software are explained. Four steps in the design of software that is more flexible are then discussed. The most critical step is the design of a software structure called the “uses” relation. Some criteria for design decisions are given and illustrated using a small example. It is shown that the identification of minimal subsets and minimal extensions can lead to software that can be tailored to the needs of a broad variety of users.