What is the principled cut between rework and maintenance?

The cleanest test: would a competent engineer have known to do this differently at the original implementation, given the information available at the time? If yes, it is rework. If no (because the environment changed in unforeseeable ways), it is maintenance. The test handles most cases cleanly. The hard cases are dependency-version upgrades that could have been deferred and security patches that were a foreseeable risk at original implementation.

What is a healthy rework-to-maintenance ratio?

Industry data suggests a healthy mature operation runs maintenance at 30 to 50% of capacity and rework at 8 to 15%, for a maintenance-to-rework ratio of 3 to 5 in favour of maintenance. An unhealthy operation often shows the opposite: rework dominant or close to maintenance. When rework exceeds maintenance, the team has a preventable-cost problem that prevention investment can address.

Rework vs Maintenance Cost: The Distinction That Saves Budget Fights

Q: What share of engineering time is maintenance?

Capers Jones and the broader software measurement literature place maintenance at 60 to 80% of total lifetime engineering cost for a typical commercial software product, with much of that concentrated in the years after initial release. The figure is much smaller for a single calendar year (typically 30 to 50% of current-year capacity), with rework typically running 15 to 30% on top.

Updated May 2026. Companion to rework vs technical debt.

TL;DR

Maintenance is keeping shipped software working as the surrounding environment changes (dependencies, OS, APIs, security baselines).
Rework is fixing shipped software that did not meet its original requirements.
The distinction matters because rework is reducible through prevention investment; maintenance is not. Treating them as one number misdirects budget.
Healthy ratio: maintenance 30 to 50% of capacity, rework 8 to 15%. Maintenance dominant by 3 to 5x in favour of maintenance.

The principled cut

The cleanest test for whether a piece of work is rework or maintenance is to ask: would a competent engineer have known to do this differently at the original implementation, given the information available at the time? If yes, the work is rework (the original implementation failed a knowable requirement). If no (because the environment changed in unforeseeable ways), the work is maintenance (the original implementation met its requirements but the world moved).

The test handles most cases cleanly. A bug discovered in code that should have been caught by unit tests: rework. A dependency upgrade required because the upstream library deprecated a method: maintenance. A security patch for a vulnerability that was disclosed after the original implementation: maintenance. A security patch for a vulnerability that was already known at the time of the original implementation: rework (because the requirements implicitly included not shipping known vulnerabilities).

The hard cases are dependency-version upgrades that could have been deferred (is staying on an old version a knowable failure?), and security patches that were a foreseeable risk at original implementation (does the team have to predict every future CVE?). For these cases, the cleanest operational test is the "reasonable contemporaneous practice" standard: would a competent team operating on the original timeline have invested in the prevention that would have made this fix unnecessary? If yes, count it as rework; if no, count it as maintenance.

The five canonical maintenance categories

Adaptive maintenance: Changes to keep the software working as the environment changes (new OS versions, new browser versions, new mobile device sizes, new third-party API contracts). Usually maintenance; sometimes rework if the original team should have made the software more portable.
Perfective maintenance: Non-functional improvements (performance, security, observability) to already-working software. Usually maintenance; some perfective work crosses into rework when the original implementation should have met the performance or security bar.
Corrective maintenance: Bug fixes. This is the category that is almost always also rework. Lehman's software evolution laws (Lehman 1969 onwards) put corrective maintenance at 17 to 21% of typical maintenance effort.
Preventive maintenance: Refactoring, restructuring, and modernisation to prevent future failure. This is the prevention spend that helps avoid future rework. It is rarely counted as rework even when it touches existing code.
Compliance maintenance: Updates driven by changes in regulatory, accessibility, or security standards. The regulatory-compliance rework page covers the rework-vs-maintenance distinction within this category specifically.

Why the distinction matters at budget time

Rework cost can be reduced through better prevention investment: design review, shift-left testing, spec quality work, requirements stability. Maintenance cost cannot. Maintenance is a function of how much shipped software exists, how fast its environment changes, and how regulated the operating context is. The team can affect the slope of maintenance cost (well-architected software is cheaper to maintain) but cannot eliminate it.

Treating maintenance as rework leads to misdirected investment. A team that books all dependency-upgrade work as rework will see its rework number stay stubbornly high no matter how much testing it adds, because testing does not reduce dependency upgrades. The team will eventually conclude that prevention does not work, when really the problem is that the wrong cost was being measured.

Treating rework as maintenance is the opposite problem and is more common. A team that books bug fixes as "maintenance" in monthly reporting hides the preventable cost, which means leadership never sees the case for prevention investment. The bug-fix cost stays the same year after year because the team has no organisational pressure to reduce it. The clean separation in measurement is the first step in unlocking prevention investment that would actually pay back.

The healthy ratio

A mature engineering operation typically runs maintenance at 30 to 50% of current-year capacity and rework at 8 to 15%, for a maintenance-to-rework ratio of roughly 3 to 5 in favour of maintenance. The maintenance share rises with product age (older products have more shipped surface to maintain); the rework share is roughly independent of product age once the team reaches steady state.

When the rework share approaches or exceeds the maintenance share, the team has a preventable-cost problem. The first investment to consider is usually improving the requirements clarity and design review discipline (see the requirements-change page and the design-defect page), which addresses the two largest single rework drivers. The investment shape and expected payback are covered on the reduce page.

Sources

Lehman, M. M. and Belady, L. A. Program Evolution: Processes of Software Change. Academic Press, 1985.
Jones, C. Applied Software Measurement. 3rd ed. McGraw-Hill, 2008.
Swanson, E. B. The Dimensions of Maintenance. Proceedings of the 2nd International Conference on Software Engineering, 1976. (The original adaptive/perfective/corrective taxonomy.)
ISO/IEC 14764:2006 Software engineering -- Software life cycle processes -- Maintenance.
Boehm, B. Software Engineering Economics. Prentice-Hall, 1981.

Frequently asked questions

What is the difference between rework and maintenance?▼

Rework is fixing software that did not meet its original requirements. Maintenance is keeping software that did meet its requirements working as the surrounding environment changes. The categories overlap but treating them as one number leads to bad budget calls.

What share of engineering time is maintenance?▼

Capers Jones places maintenance at 60 to 80% of total lifetime engineering cost. For a single calendar year, maintenance typically runs 30 to 50% of capacity, with rework 15 to 30% on top.

What is the principled cut?▼

Would a competent engineer have known to do this differently at the original implementation, given the information available at the time? If yes: rework. If no (environment changed in unforeseeable ways): maintenance.

Why does the distinction matter?▼

Rework can be reduced through prevention investment; maintenance cannot. Treating maintenance as rework misdirects investment (more testing of code with no defect-rate problem). Treating rework as maintenance hides preventable cost.

What is a healthy ratio?▼

Maintenance 30 to 50% of capacity, rework 8 to 15%, for a 3 to 5x maintenance-to-rework ratio. When rework approaches or exceeds maintenance, there is a preventable-cost problem worth investing to address.

How does this relate to Lehman's laws?▼

Lehman's laws of software evolution (1969 onwards) describe how shipped software inevitably grows in complexity and requires ongoing maintenance. Lehman's framework is the theoretical foundation for why maintenance cost is irreducible. Rework cost, by contrast, sits outside Lehman's laws and is more directly under team control.