Is maintenance just fixing bugs?

No. Bug fixing (corrective maintenance) is only one category; most maintenance effort is adaptive and perfective — adjusting software to new environments and adding or improving capabilities — which together exceed corrective work in typical systems.

Why does software complexity tend to grow over time?

As Lehman observed, continual changes to satisfy evolving needs add structure and special cases; unless effort is deliberately spent on restructuring and reducing complexity, the system becomes progressively harder to change.

Software Maintenance and Evolution

Software maintenance and evolution concern the modification of software after delivery and the long-term dynamics by which systems must continually change to remain useful.

Definition

Software maintenance is the modification of a software product after delivery to correct faults, improve performance, or adapt it to a changed environment, and software evolution is the broader, ongoing process by which software changes over its lifetime in response to shifting requirements and environments.

Scope

This area covers the categories of maintenance (corrective, adaptive, perfective, preventive); the empirical laws of software evolution; program comprehension and impact analysis; reengineering, reverse engineering, and migration of legacy systems; the accumulation and management of technical debt; and the processes and standards governing maintenance such as ISO/IEC 14764.

Sub-topics

Core questions

What categories of change make up maintenance, and how do they differ?
What empirical laws govern how software must evolve over time?
How is legacy software understood, restructured, and migrated?
How does technical debt accumulate and how is it managed?

Key theories

Categories of software maintenance: Maintenance is classified as corrective (fixing faults), adaptive (responding to environment change), perfective (improving function or performance), and preventive (improving maintainability), with adaptive and perfective work dominating in practice.
Lehman's laws of software evolution: Lehman observed that systems in active use must continually change or become progressively less satisfactory, and that as they evolve their complexity increases unless work is done to reduce it.

Clinical relevance

Maintenance typically consumes the majority of a system's total lifetime cost, so understanding evolution dynamics, controlling complexity growth, and managing technical debt are decisive for the long-term economics and viability of software.

Evidence & guidelines

ISO/IEC 14764 defines the software maintenance process, and the SWEBOK Software Maintenance knowledge area provides consensus guidance on maintenance categories, activities, and techniques.

History

Recognition that maintenance dominates software cost grew in the 1970s; Lehman and Belady formulated the laws of software evolution from empirical study of large systems, and reengineering and legacy-modernization techniques developed as long-lived systems aged and technical debt became a recognized concern.

Debates

Maintain, reengineer, or replace legacy systems: Deciding whether to keep maintaining, restructure, or wholly replace an aging system is a recurring strategic debate, balancing the risk and cost of replacement against the rising cost and fragility of continued maintenance.

Key figures

Meir M. Lehman
Les Belady
Ian Sommerville

Seminal works

lehman1980
iso14764
sommerville2015

Frequently asked questions

Is maintenance just fixing bugs?: No. Bug fixing (corrective maintenance) is only one category; most maintenance effort is adaptive and perfective — adjusting software to new environments and adding or improving capabilities — which together exceed corrective work in typical systems.
Why does software complexity tend to grow over time?: As Lehman observed, continual changes to satisfy evolving needs add structure and special cases; unless effort is deliberately spent on restructuring and reducing complexity, the system becomes progressively harder to change.