Why maintenance should improve software

What does maintenance actually cover?

There is an international standard for this, and it is rarely cited by the firms selling maintenance. ISO/IEC/IEEE 14764 divides the work along two axes, whether the change is reactive or proactive and whether its goal is correction or enhancement, and names the four categories that result.

Corrective maintenance repairs faults after they are found. Adaptive maintenance keeps software usable as its environment changes. Perfective maintenance improves performance, maintainability and other attributes. Preventive maintenance corrects latent faults before they surface in the live system.

Most support contracts describe corrective work and price it as maintenance. Measured against the standard, that is one category of four, and the software gets steadily worse on the other three.

The four categories, ISO/IEC/IEEE 14764

CorrectiveReactive · correction

Repairing faults discovered after delivery.

AdaptiveReactive · enhancement

Keeping software usable as its environment changes.

PerfectiveProactive · enhancement

Improving performance, maintainability and other attributes.

PreventiveProactive · correction

Correcting latent faults before they surface.

Software does not decay. Its surroundings move

Nothing in a codebase changes while it sits untouched. Everything around it does. Runtimes reach end of support, libraries publish advisories, browsers withdraw behaviour, providers deprecate APIs, certificates expire, and regulations arrive with dates attached.

A system that is not maintained is therefore not staying still. It is losing ground relative to the environment it runs in, and the cost of catching up compounds. The standard captures this in a single category, adaptive maintenance, which is the one most often omitted from a fixed-price support agreement because nothing appears to be broken.

What separates support that preserves from support that improves?

What happens between incidents.

A preserving retainer waits for a ticket, resolves it, and returns to waiting. The measurement it reports is response time, which describes the vendor rather than the software. Nothing about the system is different at the end of the year, except that it is twelve months further behind its dependencies.

An improving retainer holds a standing backlog and spends a fixed share of monthly capacity on it. Dependency and runtime currency. Security patching, with the advisories that drove it. Removing the cause of the most frequent ticket rather than closing instances of it. Keeping the deployment path exercised. Adding the observability needed to see the system without asking the vendor.

The difference becomes visible in the monthly report, which is why the report is worth arguing about. A report that lists incidents closed is describing activity. A report that also shows what changed, what was removed, and what is now current is describing the condition of the software.

Deployability is a maintenance property

A system that has not been released for six months has an untested path to production, and the discovery usually happens under pressure. A critical advisory arrives, the patch is trivial, and the deployment takes a week because nobody has run it recently, the credentials have rotated, and the pipeline depends on an image that no longer builds.

Regular small releases are therefore a maintenance control rather than a delivery preference. The organisations that can patch quickly are the ones that deploy often enough for the path to stay warm.

The economics, stated carefully

CISQ estimated the cost of poor software quality in the United States at approximately US$2.41 trillion in 2022, with accumulated technical debt around US$1.52 trillion. These are modelled national estimates rather than measurements, and they should be quoted as such. What they support is the direction of the argument: deferred maintenance accumulates, and the accumulation is large enough to be visible at national scale.

At the level of a single system the mechanism is easier to see. Every deferred upgrade makes the next one larger, because upgrades that could have been sequential become simultaneous. Dependency chains that were two versions behind become five, at which point the change stops being routine and starts requiring a project.

What we do differently

Where Agile Labs takes over a system for support, the engagement includes work that has nothing to do with tickets: dependency currency, deployment and rollback improvement, and removing the cause of whatever is generating the most incidents. The monthly report says what improved as well as what broke.

The claim we make is narrow and checkable. Recurring incidents should disappear rather than be closed faster, and a client should be able to see that in the numbers over a year. Systems we have supported for five years and more are the evidence we point to, and the reason those relationships lasted is that the software was in better condition each year than the year before.