No Silver Bullet: Esnce 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, becau they transform unexpectedly from the familiar into horrors. For the, one eks bullets of silver that can magically lay them to rest.
The familiar software project, at least as en by the nontechnical manager, has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of misd 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 do.
But, as we look to the horizon of a decade hence, we e no silver bullet. There is no single development, in either technology or in management technique, that by itlf promis 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 propod.
pod
Skepticism is not pessimism, however. Although we e no startling breakthroughs--and indeed, I belie
ve such to be inconsistent with the nature of software--many encouraging innovations are under way. A disciplined, consistent effort to develop, propagate, and exploit the 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 dia was replacement of demon theories and humours theories by the germ theory. That very step, the beginning of hope, in itlf dashed all hopes of magical solutions. It told workers that progress would be made stepwi, 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?--Esntial 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 e twofold gains every two years.broadcom
First, one must obrve 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 en six orders of ma
gnitude in performance price gain in 30 years. In no other technology can one choo to take the gain in either improved performance or in reduced costs. The gains flow from the transformation of computer manufacture from an asmbly industry into a process industry.
Second, to e what rate of progress one can expect in software technology, let us examine the difficulties of that technology. Following Aristotle, I divide them into esnce, the difficulties inherent in the nature of software, and accidents, tho difficulties that today attend its production but are not inherent.
The esnce of a software entity is a construct of interlocking concepts: data ts, relationships among data items, algorithms, and invocations of functions. This esnce is abstract in that such a conceptual construct is the same under many different reprentations. It is nonetheless highly preci 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 reprenting it and testing the fidelity of the reprentation. 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 esnce of modern software systems: complexity, conformity, changeability, and invisibility.
Complexity. Software entities are more complex for their size than perhaps any other human construct becau 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 clod. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.
Digital computers are themlves 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.
Likewi, a scaling-up of a software entity is not merely a repetition of the same elements in larger sizes, it is necessarily an increa in the number of different elements. In most cas, the elements interact with each other in some nonlinear fashion, and the complexity of the whole increas much more than linearly.
The complexity of software is an esntial property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its esnce. 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 tho properties by experiment. This paradigm worked becau the complexities ignored in the models were not the esntial properties of the phenomena. It does not work when the complexities are the esnce.
Many of the classic problems of developing software products derive from this esntial complexity and its nonlinear increas 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 u. 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 curity trapdoors.
statusquo
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 loo 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, becau 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. The differ from interface to interface, and from time to time, not becau of necessity but only becau they were designed by different people, rather than by God.
In many cas, the software must conform becau it is the most recent arrival on the scene. In others, it must conform becau it is perceived as the most conformable. But in all cas, much com
plexity 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 cour, so are buildings, cars, computers. But manufactured things are infrequently changed after manufacture; they are superded by later models, or esntial changes are incorporated into later-rial-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 becau 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 becau 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, rve to dampen the whims of the changers. All successful software gets changed. Two process are at work. First, as a software product is found to be uful, people try it in new cas at the edge of or beyond the original domain. The pressures for extended function come chiefly from urs who like the basic function and invent new us for it.
Second, successful software survives beyond the normal life of the machine vehicle for which it is fir
st 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, urs, laws, and machine vehicles. The 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, rve the same purpo. 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 reprentation 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 veral, general directed graphs superimpod one upon another. The veral graphs may reprent the flow of control, the flow of data, patterns of dependency, time quence, name-sp
ace relationships. The 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 u some of its most powerful conceptual tools. This lack not only impedes the process of design within one mind, it verely 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 tho difficulties have been accidental, not esntial, difficulties. We can also e 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 u of high-level languages for programming. Most obrvers credit that development with at least a factor of five in productivity, and with concomitant gains in reli
ability, 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, quences, 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 clor and clor to the sophistication of urs.
Moreover, at some point the elaboration of a high-level language creates a tool-mastery burden that increas, not reduces, the intellectual task of the ur who rarely us the esoteric constructs.
buzzwordTime-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.
egm什么意思
Time-sharing attacks a quite different difficulty. Time-sharing prerves 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 rious 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 esntial 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 respon time. As this respon time goes to zero, at some point it pass the human threshold of noticeability, about 100 milliconds. Beyond that threshold, no benefits are to be expected.
Unified programming environments. Unix and Interlisp, the first integrated programming environments to come into widespread u, em to have improved productivity by integral factors. Why?
They attack the accidental difficulties that result from using individual programs together, by providin
g integrated libraries, unified file formats, and pipes and filters. As a result, conceptual structures that in principle could always call, feed, and u one another can indeed easily do so in practice.
2013年高考日期This breakthrough in turn stimulated the development of whole toolbenches, since each new tool could be applied to any programs that ud the standard formats.
Becau of the success, environments are the subject of much of today's software-engineering rearch. We look at their promi and limitations in the next ction. 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 esnce, 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-purpo 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 su
btted 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 u for the incread 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 u 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 tho
