Siluer Bullet Essence and Accidents of Software Engineering Frederick P. Brooks, Jr. University of North Carolina at Chapel Hill Fashioning complex conceptual constructs is the essence; accidental tasks arise in representing the constructs in language. Past progress has so reduced the accidental tasks that future progress now depends upon addressing the essence. 10 fl the monsters that fil the O nightmares of or flktore, none tery more than werewolves, because they transform unexpectedly from the familar into horors, For these, one srk bullets of iver tha can magic ally lay them to ret. ‘The ailiar software projec, at east as seen by the nontechnical manager has Something of hischaracter susan nocent and stghforward bt icapable Of becoming a monster of mised shed- tues, blown budgets, and flawed products So we hear desperate cit for a siver builet—somethingto make softwar cots drop as rapidly as computer hardware cost do, But, a8 we look to the horizon of a decade hence, we se n0 slver ballet There sno single development, n ether technology or in management echnigue that by tse promise even one orderof- mmapitude improvement in producti, inrelbty, in simply. nthis ate, shal ty to show why, by examining both thenatureofthesoftare problem andthe proper ofthe bulls proposed. Skepticism ir not pessimism, however Although we see no startling break- ‘Tsar was fis pablsbedin Information Proves. dng 6 ISBN No, 0444100773, Ho) Kale, hover Sense Pubes BY. (Nowh Halas) © TIP 1586. throughs—and indeed, I believe such to be inconsistent with the nature of soft- \ware—many encouraging innovations a 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 isa 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, initseif 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 neering 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 in- ventions that will do for software prod- uctivty, reliability, and simplicity what electronics, transistors, and large-scale integration’ did for computer hardware. ‘COMPUTERBn oo West apeceeoswaadgin onde magne mote ses han imam oben the anon- Levin aseatngupotasofonen- corre ele Se of Suioutatsofwae progression, Uy isnot merely aren of these mre Be oe comes ‘but that computer hardware progress isso elements in larger sizes, itis necessarily an ‘comes the difficulty of invoking function, fast. Noother technology sincecivilization increase in the number of different cle. which makes programs hard to use. From beuanhasensixordesofmagiudein men. Innestcumrecenentincact cones mens ME 0 we Fon Performances pin n30 yea. Inno wiheachoberinsonenoninesrfsion, cies ea ee ‘other technology can one choose to take and the complexity of the whole ‘increases tions without creating side effects. From difficulty of enumerating, much less the gain in either improved performance much more than linearly. complexity of structure come the un- enter costs. These gxnsfow from ‘The compleity of software isanessen-vinualzed sates tha consitute seurey {hetransformationof computer manufac- tial property, not an accidental one. trepdeos {ure fom an assembly industryintoapro- Hence, descriptions of a software entity "Not only technical problems, but cess industry, that abstract away its complexity often management problems as well come from Second, ose whatrateofprogessone Sita avay is esence Forte cen” the caanie, eek on can expect in software technology, ews LES, mathematics and the physica! thus impeding comer ee ee amine the difficulties of that tech- selenessmade great stidesbycontirucing taker irhaee poate wee nology. Following Arot, Ldividethem Simpliiedmodesofcomplexphenonens, loots ene I one inten, thedifclisinhereat inthe evng properties from the mode, and leaning ed tases een sauE nature of software, and accidents, those _Yerifying those properties by experiment. makes ‘personnel turnover a disaster. difficulties that today attend its produe- This paradigm worked because the com- isa tar ere es Pleuts ignored inthe models were not Conformity. Software people are not Theesence of asofivareenityisacon- the esenialpropertesofthephenomena. alone in fating complete Pegi tne struct of interlocking coneps: data ses, Moet ot work when the complexities are eee See rey a Ma cease ees eres ‘essence is abstract in that such a concep- Pins software products derive from this {Maloomtntisthesame ndernennate eSental comply and is soclves he ferent representations. It is nonetheless ‘feases with size. From the complexity frbrctnpeerpetincin comes the difflcuty of communication 1 aleve the hard par of bing soft. ORE team mers, which leads ware to be the specification, design, and ‘© Product flaws, cost overruns, testing of this conceptual construct, not Schedule delays. From the ‘the labor of representing it and testing the CO™plexity comes the JSidlity of the representation. We stl make syntax errors 0 be sure but they are fuzz compared’ with the conceptual rors in mos ystems IF this is tue, building sofware wit always be har. “There is inherently no silver bullet Let us conser the inerent properties of thisireduible eence of modern soft ware sjsiemt: complexity, conformity, changeabilty, and invisbilty. ‘Complexity. Software entities are more ‘complex for their size than perhaps any ‘other human construct because no two parts are alike (at east above the statement level) 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with terribly complex objects even at the “fundamental” particle level. The phys- feist labors on, however, in a firm faith that there are unifying principles to be found, whether in quarks or in unified- field theories. Einstein argued that there ‘must be simplified explanations of nature, because God is not capricious or arbitrary. "No such faith comforts the software en- sineer. 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 timeto time, not because of necessity but only because they were designed by different people, rather than by God. In many cases, the software must con- form because itis the most recent arrival fon the scene. In others, it must conform because it is perceived as the most conformable, But in all cases, much com- plexity comes from conformation to other interfaces; this complexity cannot be simplified out by any redesign ofthe soft- ware alone. Changeabilty. The software entity is constantly subject to pressures for change. Of course, so are buildings, cars, com- puters. But manufactured things areinfre- ‘quently changed after manufacture; they are superseded by later models, or essen- tial changes are incorporated into lates 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 uch less frequent than modifications 10 fielded software In par, thisisso because thesoftware of ‘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—itis pure thoughtstuff, 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 areat work. Firs, asasoft- ‘ware product is found to be useful, people try itin new cases atthe edge of or beyond the original domain, The pressures for ex tended function come chiefly from users who lke the basic Function and invent new uses fo Second, successful software survives beyond the normal life of the machine vehicle for which it is first written. If not 2 new computers, then at last new disks, new displays, new printers come along; and the software must be conformed tits new vehicles of opportunity. Inshort the software product is embed- ded in a cultural matrix of applications, users, laws, and machine vehicles. These all change continually, and their changes inexorably force change upon the oftware product. Invisibility. Software isinvsibleand un- visualizable. Geometric abstractions are powerful tools. The floor plan of a build- ing helps both architect and client evaluate spaces, traffic flows, views. Contra- dictions and omissions become obvious. Despite progress in restricting and simplifying software structures, they remain inherently unvisualizable, and thus do not permit the mind to use some of its most powerful conceptual tools. Scale drawings of mechanical parts and stick-figure models of molecules, al- though abstractions, serve the same pur- pose. A geometric reality is captured in a geometric abstraction. "The reality of software isnot inherently embedded in space. Hence, ithasno ready ‘geometric representation in the way that land has maps, silicon chips have dia- grams, computers have connectivity schematics. As soon as we attempt to dia- gram software structure, we find it to con- stitute not one, but several, general directed graphs superimposed one upon another. The several graphs may represent the flow of contro, the low of data, pat- terns of dependency, time sequence, namespace relationships. These graphs are usually not even planar, much less hierarchical. Indeed, one of the ways of ‘stabishing conceptual control over such structure is (0 enforce link cutting until ‘one or more of the graphs becomes hierat- chica! 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 soft- ware-technology development that have ‘been most fruitful in the pas, we discover that each attacked a different major dif ficult in building software, but that those ifficulties have been accidental, not ‘essential, difficulties. We can also see the ‘natural limits tothe extrapolation ofeach such attack. High-level languages. Surely the most powerfulstroke for software productivity, reliability, and simplicity has been the pro- ‘pressive use of high-level languages for programming. Most observers credit that development with atleast a factor of five in produetivity, and with concomitant gains in reliability, simplicity, and com- rehensibilty ‘What does a high-level language ac- ccomplish? It frees a program from much of its accidental complexity. An abstract program consists of conceptual con- structs: operations, data types, sequences, ‘and communication, The concrete ma- chine program is concerned with bits, res- rs, conditions, branches, channels, disks, and such, To the extent that the high-level language embodies the con- struts one wants in the abstract program and avoids all lower ones, it eliminates a whole level of complexity that was never inherent inthe program at all ‘The most a high-level language can dois to furnish all the constructs that the pro- ‘grammer imagines in the abstract pro- ‘gram. To be sure, the level of our thinking about data structures, data types, and operationsis steadily rising, butatanever- decreasing rate. And language devel- ‘opment approaches closer and closer to the sophistication of users, ‘Moreover, at some point the elabor tion of ahigh-levellanguagecreatesatool- mastery burden that increases, not re- duces, the intellectual task ofthe user who rarely uses the esoteric constructs. ‘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 ‘COMPUTER