Abstract: The Fizzle in the Computer Revolution? Software Maintenance as Management
In theory, software is a technology that cannot be broken. Virtual gears do not require lubrication, and digital constructs never fall apart. Once a software-based system is working properly, it should continue to work in perpetuity --- or at least as long as the underlying hardware platform it runs on remains intact. Any latent "bugs" that subsequently revealed in the software system are considered flaws in the original design or implementation, not the result of the wear-and-tear of daily use, and ideally could be completely eliminated by rigorous development and testing methods.
In practice, however, most software systems are in constant need of repair. Beginning in the early 1960s, large-scale computer users discovered, much to their dismay, that between 50% and 70% of all their operating expenditures were being devoted to "software maintenance." This meant that most computer programmers were (and are) spending most of their time "maintaining" other people's computer code. As David Edgerton has suggested, although maintenance is probably the central activity of most technological societies, maintenance work is generally considered low-status, difficult, and risky. And since engineers and inventors do not like maintenance, and generally do not do maintenance, historians of science and technology have largely ignored it. This neglect is particularly true in the case of software maintenance.
In this paper, I situate the long history of the crisis in software maintenance in the context of what Bruno Latour and John Law have described as "heterogeneous engineering." Despite the fact that the material costs associated with building software applications are small (in comparison with traditional, physical systems), the degree to which software is embedded in larger, heterogeneous systems makes starting from scratch almost impossible. Frederick Brooks famously likened programming to poetry, suggesting that “The programmer, like the poet, works only slightly removed from pure-thought stuff.” For an individual programmer at the beginning of a new coding project, this might indeed be the case. But for teams of programmers maintaining so-called “legacy” software systems system, the relevant literary metaphor is not the blank slate, but the palimpsest. As both the Y2K crisis and more recent disasters in computer security revealed, the digital infrastructure of modern society is built on a foundation of fragile systems that require constant maintenance. For a technology that is uniquely ephemeral, software systems are remarkably durable.