Information Technology Reference
In-Depth Information
analysts, described as “responses to changes in the business environ-
ment.”
9
This wonderfully fl exible phrase includes the introduction of
new functionality, as dictated by market, organizational, or legislative
develops and changes in the larger technological or organizational system
in which the software is inextricably bound. Software maintenance also
incorporates such apparently nontechnical tasks as “understanding and
documenting existing systems; extending existing functions; adding new
functions; fi nding and correcting bugs; answering questions for users and
operations staff; training new systems staff; rewriting, restructuring,
converting, and purging software; managing the software of an opera-
tional system; and many other activities that go into running a successful
software system.”
10
By the early 1980s, the industry and technical litera-
ture had settled on a shared taxonomy for talking about software main-
tenance: There was corrective maintenance (bug fi xes), perfective
maintenance (performance improvements), and adaptive maintenance
(adaptations to the larger environment). Adaptive maintenance so
dominated real-world maintenance that many observers pushed for an
entirely new nomenclature; software maintenance was a misnomer, they
argued: the process of adapting software to change would better be
described as “software support,” “software evolution,” or “continuation
engineering.”
11
The concept of adaptive maintenance captures neatly what has been
referred to throughout this history as the “heterogeneous” nature of
software. Despite their seemingly intangible nature, software applica-
tions are always inextricably linked to a network of social and techno-
logical systems. This means that although the material costs associated
with building software are low (in comparison with traditional, physical
systems), the degree to which software is embedded in larger, heteroge-
neous systems makes starting from scratch almost impossible. Consider
Frederick Brooks's widely cited claim that “the programmer, like the
poet, works only slightly removed from pure-thought stuff. He builds
his castles in the air, from air, creating by exertion of the imagination.”
12
To a certain degree, this is true—at least when the programmer is
working on constructing a new system. But when charged with maintain-
ing a “legacy” system, the programmer is working not with a blank slate
but a palimpsest. The ease with which computer code can be written,
modifi ed, and deleted belies the durability of the underlying artifact.
Because software is a tangible record, not only of the intentions of the
original designer but of the social, technological, and organization
context in which it was developed, it cannot be easily modifi ed. “We
