apparently nontechnical tasks as documenta-tion, training, support, and management.6 Inthe technical literature that emerged in the1980s, this ‘‘adaptive’’ dimension so domi-nated the larger problem of maintenancethat some observers pushed for the abandon-ment of the term maintenance altogether. Theprocess of adapting software to change wouldbetter be described as ‘‘software support,’’‘‘software evolution,’’ or (my personal favor-ite) ‘‘continuation engineering.’’7

Imaginary yet tangibleIn his highly regarded book The Mythical

Man-Month, the computer scientist (andIBM program manager) Frederick Brooks fa-mously likened programming to poetry,suggesting that ‘‘The programmer, like thepoet, works only slightly removed frompure-thought stuff. He builds his castles inthe air, from air, creating by exertion of theimagination.’’8 To a degree, Brooks’s fancifulmetaphor is entirely accurate—at least whenthe programmer is working on constructinga new system. But when charged with main-taining a so-called legacy system, theprogrammer is working not with a blankslate but a palimpsest. Computer code is in-deed a kind of writing, and softwaredevelopment a form of literary production.But the ease with which computer code canbe written, modified, and deleted belies thedurability of the underlying document. Be-cause software is a tangible record, not onlyof the intentions of the original designerbut of the social, technological, and organiza-tion context in which it was developed, itcannot be easily modified. ‘‘We never havea clean slate,’’ argued Bjarne Stroustrup, cre-ator of the widely used C++ programminglanguage: ‘‘Whatever new we do must makeit possible for people to make a transitionfrom old tools and ideas to new.’’9 In thissense, software is less like a poem and morelike a contract, a constitution, or a covenant.Despite the fact that the material costs associ-ated with building software are low (incomparison with traditional, physical sys-tems), the degree to which software isembedded in larger, heterogeneous systemsmakes starting from scratch almost impossi-ble. Software is history, organization, andsocial relationships made tangible.

One of the remarkable implications of allthis is that the software industry, whichmany consider to be one of the fastest-moving and most innovative industries inthe world, is perhaps the industry most con-strained by its own history. As one observerrecently noted, today there are still morethan 240 million lines of computer code writ-ten in Cobol, which was first introduced in1959.10 All of this Cobol code needs to beactively maintained, modified, and expanded.Maintenance is central to the histories of soft-ware, computing, and technology. We needto know more about it, and we need to takeit more seriously.

For practitioners, the tangled web ofhistory embedded within legacy code is pre-cisely what makes software maintenance sodifficult; for historians, it represents only aremarkable opportunity.

References and notes1. M.S. Mahoney, ‘‘What Makes the History of

Software Hard,’’ IEEE Annals of the History of

Computing, vol. 30, no. 3, 2004, pp. 8-18.

2. D. Edgerton, The Shock of the Old: Technology

and Global History since 1900, Oxford Univ.

Press, 2007.

3. R. Canning, ‘‘The Maintenance ‘Iceberg’,’’ EDP

Analyzer, vol. 10, no. 10, 1972, pp. 1-14.

4. G. Parikh, ‘‘Maintenance: Penny Wise, Program

Foolish,’’ SIGSOFT Software Eng. Notes, vol. 10,

no. 5, 1985.

5. D.C. Rine, ‘‘A Short Overview of a History of

Software Maintenance: As It Pertains to Reuse,’’

SIGSOFT Software Eng. Notes, vol. 16, no. 4,

1991, pp. 60-63.

6. E. Burton Swanson, ‘‘The Dimensions of Main-

tenance,’’ Proc. 2nd Int’l Conf. Software Eng.

(ICSE 76), IEEE Computer Soc. Press, 1976,

pp. 492-497.

7. G. Parikh, ‘‘What Is Software Maintenance

Really? What Is In A Name?’’ SIGSOFT Software

Eng. Notes, vol. 9, no. 2, 1984, pp. 114-116.

8. F. Brooks, The Mythical Man-Month: Essays on

Software Engineering, Addison-Wesley, 1975.

9. B. Stroustrup, ‘‘A History of C++,’’ History of

Programming Languages, T.M. Bergin and R.G.

Gibson, eds., ACM Press, 1996.

10. M. Swaine, ‘‘Is Your Next Language COBOL?’’

Dr. Dobbs J., 18 Sept. 2008.

Contact department editor Nathan Ensmenger atannals-thinkpiece@computer.org.

[3B2-8] man2009010086.3d 20/2/09 13:42 Page 90

Think Piece

continued from p. 88

86 IEEE Annals of the History of Computing

[3B2-8] man2009010086.3d 20/2/09 13:42 Page 91

January–March 2009 87

Software as History EmbodiedNathan Ensmenger, Editor

In the very last published article of his long and distin-guished career, the eminent historian of computingMichael Mahoney asked a simple but profound ques-tion: ‘‘What makes the history of software hard?1 Inhis characteristically playful style, Mike was engagingboth with an issue of central importance to historians—namely, how can we begin to come to grips with theformidable challenges of writing the history of software—but also one of great interest to practitioners.

Since electronic computing’s earliest days, the prob-lem of software has loomed large in the industryliterature. The history of software is hard, Mahoneyargued, because software itself is hard: hard to design,develop, use, understand, and maintain.

It is this last challenge posed by software—the chal-lenge of software maintenance—that I take up in thisessay.

The problem of maintenance is a ubiquitous butneglected element of the history of technology. Allcomplex technological systems eventually break downand require repair (some more so than others), and, infact, as David Edgerton has suggested, maintenance isprobably the central activity of most technological soci-eties.2 But maintenance is also low-status, difficult, andrisky. Engineers and inventors don’t like maintenance,and generally don’t do maintenance—therefore, histor-ians of technology have largely ignored it.

Unbreakable software?Nowhere is this dislike of maintenance more appar-

ent than in software development. Not only aresoftware developers particularly averse to working onother people’s systems (the infamous ‘‘not inventedhere’’ syndrome), but software itself is considered essen-tially unbreakable. Software does not wear out or breakdown in the traditional sense. Once a software-basedsystem is working, it should work forever (or at leastuntil the underlying hardware breaks down—butthat’s someone else’s problem). Any latent ‘‘bugs’’ sub-sequently revealed in the system are considered flawsin the original design or implementation, not the resultof the wear-and-tear of daily use, and in theory could becompletely eliminated by rigorous development andtesting methods.

But despite the fact that software in theory neverbreaks down, in most large software projects mainte-nance represents the single most time-consuming andexpensive phase of development. Since the early1960s, software maintenance has been a continuoussource of tension between computer programmersand users. In a 1972 article, the influential industry

analyst Richard Canning argued that the rising cost ofsoftware maintenance, which by then already devouredas much as half or two-thirds of programming resour-ces, was just the ‘‘tip of the maintenance iceberg.’’3

Today, software maintenance is estimated to representbetween 50% and 70% of all software expenditures.4

So if software is an artifact that, in theory, can neverbe broken, what is software maintenance? Althoughsoftware does not wear out or break down in any tradi-tional sense, what does ‘‘break’’ over time is the largercontext of use. To borrow a concept from John Lawand Donald MacKenzie, software is a heterogeneoustechnology. Unlike computer hardware, which is by def-inition a tangible ‘‘thing’’ that can be readily isolated,identified, and evaluated (and whose maintenance canbe anticipated and accounted for), computer softwarehas been inextricably linked to a larger sociotechnicalsystem that includes machines (computers and theirassociated peripherals), people (users, designers, anddevelopers), and processes (the corporate payroll sys-tem, for example). Software maintenance is thereforeas much a social as a technological endeavor. Usuallywhat needs to be ‘‘fixed’’ is the ongoing negotiation be-tween the expectations of users, the larger context ofuse and operation, and the features of the software sys-tem in question.

If we consider software not as an end-product or afinished good, but as a heterogeneous system, withboth technological and social components, we can un-derstand why the software maintenance problem hashistorically been so complex. To begin with, it raises afundamental question—one that has plagued softwaredevelopers since the advent of electronic computing—namely, what does it mean for software to workproperly? The most obvious answer is that it performsas expected—that the system behavior conforms to itsoriginal design specification. But only a small percent-age of software maintenance is devoted to fixing bugsin implementation.5

Most software maintenance involves what are vaguelyreferred to in the literature as ‘‘enhancements.’’ Enhance-ments sometimes involved strictly technical measures—such as implementing performance optimizations—butmost often what Richard Canning termed ‘‘responsesto changes in the business environment.’’ This includedthe introduction of new functionality, as dictated bymarket, organizational, or legislative developments,but also changes in the larger technological or organiza-tional system in which the software was inextricablybound. Software maintenance also incorporated such

[3B2-8] man2009010086.3d 20/2/09 11:37 Page 88

Think Piece

continued on p. 86

88 IEEE Annals of the History of Computing 1058-6180/09/$25.00 �c 2009 IEEEPublished by the IEEE Computer Society