Ninety per cent of the life of a program is maintenance

The claim in circulation

Some proportion of a program's total cost, usually given as sixty, eighty or ninety per cent, is spent after it is first delivered. The figure is used to argue for readable code, for documentation, and for spending more time on design.

Those are good arguments. The figure attached to them is doing less work than it appears to.

1980The survey underneath it

The most-cited source is a survey of several hundred organisations conducted at the end of the nineteen-seventies, asking how effort on existing systems divided.

It found that a majority of effort went to work on delivered systems, in the region of half to two thirds depending on how the question was framed. The higher figures in circulation are not from that survey.

The part that is always dropped

The survey divided the work by kind, and the largest category by some distance was adding functionality that was wanted after delivery. Correcting defects was a minority, on the order of a fifth.

So the number does not say what it is used to say. It is not evidence that most of software work is repairing mistakes. It is evidence that most of software work is changing software that already works, which is a description of the job rather than an indictment.

Why that distinction matters

The two readings recommend opposite things. If most of the cost is repair, the remedy is to make fewer mistakes: more specification, more verification, more caution.

If most of the cost is change, the remedy is to make change cheap: structure that can be modified, tests that permit modification, and delivery that does not make each change an event. Those are different investments and the figure has been used to justify both.

The word itself is the problem

Maintenance borrows from physical engineering, where it means keeping a thing in the condition it was built in: replacing worn parts, resisting decay.

Software does not wear. It stops being suitable because the world around it changed, or because somebody wants it to do something else. Calling that maintenance imports a metaphor that makes ordinary and valuable work sound like an overhead.

2010s onwardsWhat has happened to the category

For continuously delivered systems the distinction has largely dissolved. There is no moment of delivery separating development from maintenance; there is one long sequence of changes to a running system.

Which makes the ratio unmeasurable in the way the survey measured it, and makes quoting a figure derived from a world of discrete releases into a claim about a world that no longer has them.

What survives

The defensible statement is that most work on any long-lived system is done on code that already exists and was written by somebody else, possibly a former version of you.

That justifies everything the figure is usually invoked to justify, requires no number, and cannot be contradicted by a better survey.

What actually makes later change expensive

Not the age of the code. The absence of anybody who understands why it is the way it is, and the absence of a way to tell whether a change broke something.

Both are addressable and neither is addressed by writing more documentation at the start, which decays. What survives is tests that encode the intended behaviour and a record of why decisions were taken, which is a different investment from the one the figure is usually used to justify.

present dayThe systems nobody plans for

The distribution of software lifetimes has a very long tail. A large amount of what runs organisations was written for a purpose that no longer exists, by people who have left, in languages the current staff do not read.

Nobody estimated for that at the outset, because nobody expected the system to last, which is the same assumption behind two digits for a year and thirty-two bits for a counter. Software outlives its expected lifetime as a matter of routine, and none of the planning reflects it.

The version of the claim that is measurable

If somebody wants a number for their own organisation, it is available: the proportion of changes in the last year that touched code written more than a year ago.

That is computable from the version history in an afternoon, means something specific, and applies to the organisation asking rather than to several hundred companies surveyed before most current practitioners were born.

Where the higher figures came from

Partly from later studies with different definitions, partly from rounding, and partly from a genuine effect: the longer a system lives, the larger the share of its total cost that falls after delivery, so a figure measured on old systems is higher than one measured across all systems.

Which means the number is not simply wrong; it is conditional on a population that is rarely stated. That is the same defect as the curve in the previous entry and the ratio in the first.

What we cannot verify

The original survey is published and its categories can be read. Later figures come from studies with incompatible definitions of maintenance, and we have not attempted to reconcile them. No contemporary measurement exists that we would rely on, because the category has stopped being well defined.