Information Technology Reference
In-Depth Information
Bug; even still, the fi nal minutes prior to midnight were tense with
uncertainty.
Like most crises, the salience of the Y2K problem diminished almost
immediately upon its failure to materialize. To the average citizen, the
fuss that the computer people made about Y2K was just one of several
apocalyptic scenarios that swirled around the turn of the millennium, all
of which seem, in retrospect, self-evidently unfounded. It was diffi cult to
remember, even just a few years later, how much time, energy, and effort
were expended in addressing this latest iteration of the software crisis.
For experienced observers of the computer industry, however, the short-
comings of contemporary software development practices revealed by
Y2K were both very real and depressingly familiar. Once the proximate
technical cause of the problem had been clearly identifi ed (the short-
sighted decision, intentional or otherwise, to code calendar year data
with two digits instead of four; i.e., “72” rather than “1972”), the dis-
cussion quickly turned to the deeper, more endemic problems associated
with software development: haphazard techniques, a lack of profession-
alism, and insuffi cient managerial controls.
In many respects, the Y2K problem was just another in long series of
software crises which, as we have seen, have plagued the computer
industry since its very inception. But Y2K in particular highlighted some
of the lesser-known facets of the seemingly perpetual software crisis, the
most interesting and surprising of which was the problem of software
maintenance.
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 than others); as David
Edgerton has suggested, maintenance is probably the central activity of
most technological societies.
3
But maintenance is also low-status, diffi -
cult, and risky. Engineers and inventors do not like, and generally do
not perform maintenance, and therefore historians of technology have
largely ignored it.
The problem of maintenance is particularly challenging for both prac-
titioners and historians of computing. In theory, software should never
need maintenance because software does not break down or wear out,
at least in the conventional sense. Once a software-based system is
working, it will work forever (or at least until the underlying hardware
breaks down—but that is generally considered someone else's problem).
Occasionally a stray cosmic ray might fl ip an unexpected bit in a soft-
