Maintenance

1. What is software maintenance?

Software maintenance is the process of modifying a software product after it has been released — fixing defects, adapting it to changed environments, improving its functionality, and preventing future problems. It is the final phase of the SDLC and, in practice, the longest and costliest.

Maintenance covers everything done to the software after delivery: correcting bugs users find, updating it for new operating systems or regulations, adding features and improvements, and refactoring to keep the code healthy. It is not “fixing what went wrong” in a narrow sense — much of maintenance is the normal, continuous evolution of a living product.

Maintenance matters because software is never finished. Environments change, users demand more, defects surface, and a product that is not maintained decays — becomes slow, insecure, incompatible, and eventually unusable. The industry spends far more on maintenance than on initial development — estimates range from 60% to 80% of total lifecycle cost. Maintenance is where the real cost of software is paid.

2. What are the different types of software maintenance?

Software maintenance is traditionally classified into four types, based on why the change is being made.

Corrective maintenance fixes defects — bugs the user finds, like a crash on the payment page. It returns the software to correct behavior. Adaptive maintenance changes the software to fit a changed environment — a new operating system version, a new database, a new regulation, a new hardware platform. Perfective maintenance adds improvements and new functionality — a dark mode, a faster report, a new feature the user requests. Preventive maintenance strengthens the software to avoid future problems — refactoring messy code, adding missing tests, updating dependencies, removing dead code.

The split is about intent, and it matters for budgeting and classification. Corrective is reactive (fixing what broke), adaptive and perfective are proactive (keeping up and getting better), and preventive is future-oriented (avoiding trouble). Interviewers often test whether you can place a specific change into the right category — the golden example: a crash fix is corrective, an OS update is adaptive, a new feature is perfective, and refactoring is preventive.

3. What is corrective maintenance?

Corrective maintenance is the type of maintenance that fixes defects in the software — errors, crashes, and incorrect behavior that the user encounters after the product has been released. It is the “bug fixing” maintenance.

The activity follows a typical flow: a defect is reported, logged, and triaged by severity; it is analyzed to find the root cause; a fix is designed and implemented; and the fix is tested and verified — with regression testing to ensure the fix did not break anything else. Then the corrected version is released.

Corrective maintenance is reactive — it responds to failures that already happened. It is the most visible type of maintenance because it is driven by user complaints, and its quality depends heavily on the earlier phases: defects are cheaper to fix the earlier they are found, so corrective maintenance cost is a symptom of how well testing and reviews were done. A high volume of corrective maintenance usually signals weak requirements analysis or insufficient testing upstream. Though it is called “corrective,” some corrective work is also preventive in spirit — fixing the root cause of a class of defects rather than just the reported symptom.

4. What is adaptive maintenance?

Adaptive maintenance is the type of maintenance that modifies the software to accommodate changes in its environment — the world outside the software has changed, and the software must change to keep working in it.

The environment includes: new or upgraded operating systems and platforms; new database versions; new hardware; changed regulations and compliance rules (tax laws, data protection acts); new versions of libraries and dependencies; and integrations with external systems that have changed their interfaces.

Adaptive maintenance is driven by external change, not by defects — the software was working correctly, but the world it runs in has moved. The practical example: a mobile app updated when the target OS releases a new version, or a payroll system updated when the government changes tax rules. Adaptive maintenance is continuous and unavoidable — environments never stop evolving, so software that is not adaptively maintained progressively breaks as its environment changes. It is a large share of the maintenance budget precisely because the environment never stands still.

5. What is perfective maintenance?

Perfective maintenance is the type of maintenance that improves the software beyond its original requirements — adding new features, improving performance and usability, and enhancing the product to better serve its users. It is the “make it better” maintenance.

While corrective maintenance fixes what is broken and adaptive maintenance reacts to the environment, perfective maintenance is driven by user needs and business value: new functionality, better performance, a more intuitive interface, new reports, and improvements requested by users or competitors. A dark mode, a new export format, a faster search, and a redesigned dashboard are all perfective changes.

Perfective maintenance is typically the largest category of maintenance work — estimates suggest it consumes around 50% of maintenance effort. It is proactive and value-creating, and it is where a maintained product stays competitive. The interview point: perfective maintenance improves the product against its own goals, unlike corrective (fixing defects) and adaptive (reacting to environment) maintenance. It also requires careful management — adding features without control is how scope creep and architectural decay begin.

6. What is preventive maintenance?

Preventive maintenance is the type of maintenance that makes the software more maintainable and avoids future problems — work done now to prevent defects and decay later. It is the “keep it healthy” maintenance.

The activities include: refactoring code to improve structure without changing behavior; adding missing test coverage; updating dependencies and removing obsolete ones; removing dead code; improving documentation; and strengthening security and performance baselines. It is proactive — it happens while the software is still working, to prevent trouble before it occurs.

Preventive maintenance is the easiest to skip and the most valuable to do. It is invisible because it produces no user-visible change, so it is often cut under budget pressure — which is exactly when the software starts to decay. Its costs are paid now and its benefits arrive later: cheaper future maintenance, fewer defects, and a codebase that can evolve instead of rotting. The analogy is regular servicing of a car — the oil changes and inspections that prevent breakdowns. The interview point: preventive maintenance is proactive quality investment, distinguished from corrective (reactive), adaptive (environmental), and perfective (enhancement) maintenance.

7. Why is software maintenance necessary?

Software maintenance is necessary because software exists in a world that does not stand still, and an unmaintained product decays. There are four forces, matching the four types of maintenance.

Defects exist — no software is ever defect-free, and users keep finding bugs, so corrective maintenance is unavoidable. The environment changes — operating systems, hardware, regulations, and integrations keep moving, so the software must be adaptively maintained or it progressively breaks. Users and businesses want more — new features, better performance, better usability, so perfective maintenance is needed to keep the product valuable and competitive. And code decays — without preventive maintenance, structure erodes, tests go missing, and the software becomes increasingly expensive to change.

Beyond these, maintenance is where the financial reality of software lives: the maintenance phase typically consumes the majority of a software product’s lifetime cost, often several times the original development cost. A released product is not finished — it is a living system that must be fixed, adapted, improved, and preserved for years. How well it is maintained determines whether it thrives for a decade or decays within a year.

8. What is software re-engineering?

Software re-engineering is the process of restructuring and reworking existing software to improve its quality and maintainability without changing its external functionality. The software still does what it does — but it is rebuilt internally to be healthier.

Re-engineering typically combines activities: reverse engineering analyzes the existing software to understand its structure and recover its design (often from code with lost documentation); restructuring reorganizes the code — re-architecting modules, cleaning up dependencies — while preserving behavior; re-documentation rebuilds the documentation that was lost; and sometimes forward engineering re-implements parts with modern technology.

Re-engineering is the alternative to two extremes: leaving the decaying software alone (which gets progressively more expensive to maintain) or rewriting it from scratch (which risks losing the accumulated value and behavior). Re-engineering modernizes the internal structure while preserving the external behavior, reducing future maintenance cost. The distinction in interviews: re-engineering changes the internal structure, not the functionality — it is done to rescue software that has become too expensive to maintain.

9. What is legacy software?

Legacy software is older software that is still critical to an organization but is built with outdated technology and is increasingly difficult and expensive to maintain. It works — often crucially — but it is aging.

Typical legacy characteristics: old programming languages and platforms (COBOL, FORTRAN, old Java versions); outdated architectures (monolithic, hard-coded, undocumented); reliance on old hardware or operating systems no longer supported; a shortage of people who know how to maintain it; and poor documentation of its behavior. Yet it often runs core business operations — banking systems, insurance processing, government records — that no one wants to stop.

The legacy problem is that maintenance costs rise as the software ages and the skills to maintain it fade, while its risks grow — incompatibility, security vulnerabilities, inability to evolve. The responses range from keeping it alive (a strategy in itself), to wrapping it with modern interfaces, to re-engineering, to replacing it — the riskiest option because the legacy system’s behavior may be imperfectly understood. The interview point: legacy software is not a moral failing — it is software that has outlived its technology but not its usefulness.

10. What factors affect software maintenance cost?

Maintenance cost is driven by characteristics of the software and the organization. The software’s structure matters most: messy code, high coupling, low cohesion, and poor documentation make every change expensive, because the maintainer must understand the system before touching it. Age and technology also drive cost — legacy platforms have fewer experts and harder problems.

Requirements quality compounds maintenance cost: ambiguous or missing requirements create corrective maintenance later. Testing quality matters too — a system with good test coverage can be changed safely; one without it forces costly manual regression. The people factor — the maintainers’ knowledge of the system and the availability of original developers — dramatically affects cost; a system nobody understands is expensive to maintain.

External forces also play a role: the pace of environment change (new OSes, regulations, integrations) and the number of user change requests. And the maintenance strategy itself — reactive versus preventive — shapes cost trends: skipping preventive maintenance makes future changes exponentially more expensive. The general rule: the most maintainable software is simple, well-structured, well-documented, well-tested, and written to be understood.

11. What is the difference between software maintenance and software evolution?

Software maintenance and software evolution describe overlapping but distinct ideas. Maintenance is the operational activity of modifying software after release — the four types: corrective, adaptive, perfective, and preventive. It is the process of keeping the software working and current.

Software evolution is the broader concept that software changes over its lifetime and is never finished — the observation that software systems grow, adapt, and transform continuously throughout their life, driven by changing requirements and environments. It is a more encompassing view than the maintenance checklist: evolution includes the initial development as part of the system’s change trajectory, and it emphasizes that change is the normal state of software, not an interruption of it.

The practical distinction: maintenance is the day-to-day activity (the changes made); evolution is the long-term process (the way software systems change over years and decades). A legacy system that has survived forty years of changes is a product of evolution — the individual changes were maintenance. The interview point: maintenance answers “what work is being done to keep the software alive?” Evolution answers “how does software transform over its lifetime?“

12. Why can maintenance cost exceed development cost?

Maintenance cost can exceed development cost because the maintenance phase lasts far longer and involves far more change than the development phase. Development is typically a year or two; a successful product is maintained for five, ten, or twenty years — and every one of those years accumulates cost.

The volume of change is also larger. A product rarely sits still after release: defects are found, environments shift, users request features, and each change is a small project — analyze, change, test, release, and regression-test. Over a decade, this accumulated change work easily exceeds the original build effort. The classic estimate: 60% to 80% of a software system’s lifetime cost is spent after delivery.

The economics worsen with age. As software ages without preventive maintenance, its structure decays, its documentation fades, and its maintainers leave — so each change becomes slower and more expensive. Corrective maintenance also reflects upstream quality: a system with poor requirements and testing generates continuous defect-fixing cost. The result is the maintenance cost curve rising over time. This is why the most cost-effective engineering decisions — clear requirements, good structure, test coverage — are made early, because they are what keep the expensive maintenance phase cheap.