- Software as History Embodied
In the very last published article of his long and distinguished career, the eminent historian of computing Michael Mahoney asked a simple but profound question: "What makes the history of software hard?1 In his characteristically playful style, Mike was engaging both with an issue of central importance to historians—namely, how can we begin to come to grips with the formidable challenges of writing the history of software—but also one of great interest to practitioners.
Since electronic computing's earliest days, the problem of software has loomed large in the industry literature. The history of software is hard, Mahoney argued, because software itself is hard: hard to design, develop, use, understand, and maintain.
It is this last challenge posed by software—the challenge of software maintenance—that I take up in this essay.
The problem of maintenance is a ubiquitous but neglected element of the history of technology. All complex technological systems eventually break down and require repair (some more so than others), and, in fact, as David Edgerton has suggested, maintenance is probably the central activity of most technological societies. 2 But maintenance is also low-status, difficult, and risky. Engineers and inventors don't like maintenance, and generally don't do maintenance—therefore, historians of technology have largely ignored it.
Nowhere is this dislike of maintenance more apparent than in software development. Not only are software developers particularly averse to working on other people's systems (the infamous "not invented here" syndrome), but software itself is considered essentially unbreakable. Software does not wear out or break down in the traditional sense. Once a software-based system is working, it should work forever (or at least until the underlying hardware breaks down—but that's someone else's problem). Any latent "bugs" subsequently revealed in the system are considered flaws in the original design or implementation, not the result of the wear-and-tear of daily use, and in theory could be completely eliminated by rigorous development and testing methods.
But despite the fact that software in theory never breaks down, in most large software projects maintenance represents the single most time-consuming and expensive phase of development. Since the early 1960s, software maintenance has been a continuous source of tension between computer programmers and users. In a 1972 article, the influential industry analyst Richard Canning argued that the rising cost of software maintenance, which by then already devoured as much as half or two-thirds of programming resources, was just the "tip of the maintenance iceberg."3 Today, software maintenance is estimated to represent between 50% and 70% of all software expenditures.4
So if software is an artifact that, in theory, can never be broken, what is software maintenance? Although software does not wear out or break down in any traditional sense, what does "break" over time is the larger context of use. To borrow a concept from John Law and Donald MacKenzie, software is a heterogeneous technology. Unlike computer hardware, which is by definition a tangible "thing" that can be readily isolated, identified, and evaluated (and whose maintenance can be anticipated and accounted for), computer software has been inextricably linked to a larger sociotechnical system that includes machines (computers and their associated peripherals), people (users, designers, and developers), and processes (the corporate payroll system, for example). Software maintenance is therefore as much a social as a technological endeavor. Usually what needs to be "fixed" is the ongoing negotiation between the expectations of users, the larger context of use and operation, and the features of the software system in question.
If we consider software not as an end-product or a finished good, but as a heterogeneous system, with both technological and social components, we can understand why the software maintenance problem has historically been so complex. To begin with, it raises a fundamental question—one that has plagued software developers since the advent of electronic computing—namely, what does it mean for software to work properly? The most obvious answer is that it performs as expected—that the system behavior conforms to its original design specification. But only a small percentage of software maintenance is...