Introduction to Software Maintenance
Software maintenance is one of the most consequential — and most overlooked — activities in software engineering. While courses and textbooks devote most of their attention to the design and development of new systems, the reality of professional software work is dominated by the need to understand, adapt, and improve systems that already exist. Large open-source projects like SOFA (a simulation framework for medical applications) illustrate this dynamic well: they are never truly “finished.” They must continuously evolve — incorporating new algorithms, supporting new hardware, adapting to new APIs, and correcting the assumptions of their original authors — simply to remain useful.
What is Software Maintenance?
The ISO/IEC 14764
standard defines software maintenance as:The modification of a software product after delivery to correct faults, to improve performance or other attributes. — ISO/IEC 14764
This definition is deliberately broad: it covers not just bug fixes, but any change made to a system once it has been deployed to users.
A closely related concept is that of legacy software:
A system which continues to be used because of the cost of replacing or redesigning it, and often despite its poor competitiveness and compatibility with modern equivalents.
The term carries a negative connotation in popular culture, but it describes something fundamentally important — a system that works well enough that replacing it is more expensive, risky, or disruptive than maintaining it.
Understanding maintenance begins with recognising that software does not stand still. The moment a system is delivered, its environment begins to change around it.
Why Maintenance Matters
The Cost of Maintenance
The economic weight of software maintenance is staggering, and it has grown consistently over the past five decades. O’Reilly’s 60/60 rule captures the broad picture: roughly 60% of a software product’s total lifecycle expenses go toward maintenance rather than initial development. For mature systems that have been in production for six years or more, Gartner estimates that maintenance costs can reach 90% of total lifecycle costs.
When you consider the full picture, the numbers become even more striking:
| Era | Maintenance share of lifecycle costs |
|---|---|
| 1970s | ~40% |
| 2000s | >75% |
| Today (mature systems, 6+ years) | up to 90% |
Other indicators reinforce this trend:
- Over a 5–10 year lifecycle, maintenance typically costs 2–4 times the original development investment.
- Annual maintenance expenditure in the United States alone exceeds $70 billion by industry estimates.
Maintenance is the dominant activity in software engineering — not new development. Yet it is rarely taught and often stigmatized.
The Scale of Existing Code
To appreciate the challenge, consider the sheer volume of software already deployed in the world. A few representative examples from 2024:
- Linux kernel: approximately 30 million lines of code
- Chromium browser: approximately 35 million lines of code
- Android: approximately 15 million lines of code
- COBOL: an estimated 800 billion lines of code still in active production use, with roughly 1 billion new lines added per year (Micro Focus, 2022)
- Airbus A300: development began in 1972; support is committed through 2050 — a 78-year software lifecycle
These are not outliers. They are the norm. The software world is not a blank slate waiting for new ideas — it is an enormous accumulated investment that must be preserved, extended, and corrected continuously.
Maintenance Categories
Not all maintenance is the same. The research literature distinguishes four categories, each driven by different forces:
| Category | Description | Share |
|---|---|---|
| Perfective | Improving features and performance | ~50% |
| Adaptive | Adapting to changed environment (OS, hardware, laws) | ~25% |
| Corrective | Fixing bugs reported by users | ~20% |
| Preventive | Reducing future risk, improving maintainability | ~5% |
The most important insight from this breakdown is that most maintenance is not bug fixing. Corrective maintenance accounts for only about one fifth of the total effort. The majority — perfective and adaptive maintenance combined — is driven by evolution: new features requested by users, new platforms to support, new regulations to comply with. A system that is not actively extended and adapted will quickly be overtaken by the world around it.
Hardware vs. Software Maintenance
A common analogy compares software maintenance to hardware maintenance, but the comparison is misleading in an instructive way. Hardware wears out physically: a motor degrades, a circuit corrodes, a bearing fails. Hardware maintenance means replacing broken or worn parts.
Software, by contrast, does not wear out. A program that ran correctly yesterday will run correctly tomorrow if nothing in its environment changes. Software maintenance is therefore not fundamentally about repair — it is about evolution. The system itself is not broken; it is the relationship between the system and its environment that has changed.
This insight was formalised by Manny Lehman in 1974:
A system must be continually adapted or it becomes progressively less satisfactory. — Lehman’s First Law (1974)
Failure to maintain is not a neutral choice — it is a choice to allow a system to decline.
Software and Its Environment
Software systems do not operate in isolation. They operate within a real world that keeps changing: new laws come into force, new business models emerge, user expectations evolve, hardware platforms are replaced. A system that is not adapted to these changes eventually becomes misaligned with its environment and, ultimately, useless.
This means maintenance is mainly driven by external causes, not by mistakes made during original development. A perfectly written program, with no bugs whatsoever, will still require maintenance as the world around it shifts.
A useful analogy is that of a small building that starts as a modest shop. As the organisation grows, it needs a cafeteria, then a directors’ dining room, then a legal emergency exit, then a gym, and eventually a swimming pool. Each change is a perfectly legitimate response to a changed environment — not a correction of an error in the original design. Software systems evolve in the same way.
A system that is being maintained is a system being used. Well-developed, successful systems attract more maintenance requests — not fewer. The goal is not to eliminate maintenance but to make it manageable.
Common Misconceptions
Several persistent myths distort the way students and organisations think about software maintenance.
This is false. Even perfectly written code must change as the environment changes. No amount of upfront engineering — no matter how rigorous — prevents adaptive maintenance. The world changes, and the software must change with it.
This is also false. New development technologies target new development. They do nothing about the 800+ billion lines of code already deployed in production. Moreover, AI-generated code and model-driven systems are themselves programs — they will need to be maintained just like any other software. There is no technological shortcut that eliminates the need for human understanding and intervention.
The first part is true; the second is not. Maintenance is intellectually demanding — arguably more so than greenfield development, because it operates under more constraints with less information. Think of it as software archaeology: uncovering the intent behind code, reconstructing the decisions of the past, and making targeted interventions that preserve what works while improving what does not.
This is rarely the right call. Legacy code often works and scales — that is precisely why it is still running after decades. A rewrite introduces entirely new bugs, consumes enormous resources, and forces users to relearn tools they already know. The LOUVOIS case is instructive: France’s military payroll system rewrite was launched in 2011, abandoned in 2013, cost approximately €80 million in development, generated €465 million in pay calculation errors in 2012 alone (Cour des comptes, 2014), and resulted in over 120,000 military complaints about incorrect pay. When a rewrite is genuinely justified, an iterative re-engineering approach — not a big-bang rewrite — is far less risky.
The Cultural Problem
Beyond economics and technology, software maintenance faces a cultural problem. It is almost never taught in computer science curricula, which implicitly signals that it is unimportant or that it can be learned “on the job.” Historically, assigning developers to maintenance tasks was treated as punishment or probation — a signal that a developer was not talented enough for “real” work.
The broader software industry has long suffered from a “newer is better” mentality. Yet 1959 COBOL still runs 95% of ATM transactions worldwide. The technology underlying critical infrastructure, banking, insurance, and logistics has not been replaced — it has been maintained.
40–60% of maintenance time is spent understanding the existing system — before a single line is changed. Maintenance is fundamentally a knowledge-intensive activity, not a mechanical one.
This has practical consequences. Developers who end up doing maintenance work are often underprepared for it. They lack the tools, the vocabulary, and the mindset that the work requires. One of the goals of this course is to address that gap directly.
Preparing for Maintenance
Good engineering practice treats maintenance not as an afterthought but as a design constraint from the very beginning. Before a system is delivered, thoughtful teams ask:
- Who will maintain this system after delivery? What do they know, and what will they need to learn?
- How will knowledge be transferred from the development team to the maintenance team?
- What tooling, documentation, and test coverage exists to support future changes?
The maintenance process itself differs from the development process in important ways. The analysis phase is much longer, because understanding an unfamiliar codebase takes significant time before any change can safely be made. The work is less planned and more reactive, driven by external events — user bug reports, regulatory changes, platform updates — rather than by a structured development roadmap. It requires a different mindset and a different set of skills than initial development.
Closing Remarks
Software evolution is growing in strategic importance, not declining. The volume of deployed software continues to increase, the systems that underpin critical infrastructure are aging, and the skills needed to maintain those systems are in short supply. Investment is required: in tooling that makes large codebases navigable, in training that prepares developers for the realities of maintenance work, and in cultural change that treats maintainers as the skilled engineers they are.
The maintainer’s role is a synthesis of several disciplines: the software archaeologist who reconstructs the intent of past decisions, the surgeon who makes precise interventions in a living system, the architect who evaluates structural options under real constraints, and the detective who diagnoses failures from incomplete evidence.
The rest of this course explores concrete tools and practices that make maintenance more tractable: testing and test-driven development, clean code principles, and continuous integration pipelines. Each of these topics is valuable in new development — but they are essential in maintenance.