Writing cost, and the cost that follows it

The part of the bill nobody sees at the start

A line of code is paid for twice: once when written, and continuously thereafter by everyone who has to read it, change it, patch it and reason around it.

The old surveys put the second half at somewhere between half and four-fifths of total lifecycle cost. Lientz and Swanson surveyed several hundred organisations in 1980 and found roughly half of effort going to maintenance; later estimates ran higher. Treat those numbers with suspicion: they are old, self-reported, and everyone defined “maintenance” differently. The direction is robust even where the fraction is not: the majority of what software costs happens after it first works.

Generation cut the first payment substantially. It cut the second payment by nothing at all, and there is an argument, unproven, that it raised it.

Why the second payment might have gone up

Three mechanisms, each plausible and none measured.

Volume. More code exists per unit of delivered function, because generating an abstraction that removes duplication is more work than generating the duplication. Every line carries maintenance cost.

Fewer shared concepts. A person building a system converges: they invent a helper, then reuse it. A generator invoked separately on similar problems produces four similar-but-different solutions, because it does not remember the other three. The codebase ends up with four date parsers.

Nobody holds the model. The most expensive property of a legacy system is not that the code is bad; it is that the reasoning is gone. Code accepted rather than authored starts in that state on day one. Module six covered onboarding without an author; this is the same problem measured over years instead of weeks.

I want to be exact about the epistemic status: this is a mechanism argument. The oldest substantially generated codebases are about three years old, and maintenance costs become visible at five to ten. Nobody has the data yet, and anyone claiming to is extrapolating.

What makes code cheap to keep

Notably, not the same things that make it fast to write.

Fewer distinct concepts. Ten modules using one date library and one error convention is cheaper than ten modules each locally optimal. Consistency beats local quality for maintenance, which is a counterintuitive claim and the reason style guides exist.

Deletability. Can this be removed without archaeology? Clear boundaries and few reverse dependencies are what let a system shrink, and a system that can never shrink only grows.

Boring choices. The widely used library with five years of history costs less over a decade than the elegant one with a single maintainer, whatever the comparison looks like today.

Fewer dependencies. Each is a permanent obligation to track advisories, absorb breaking changes and eventually migrate. Dependency count is debt that accrues interest whether or not you touch the code.

Two measurements you can take this week

Count the ways. Pick something your codebase does repeatedly: parse a date, retry a call, format money, check a permission. Count the distinct implementations. Most teams find three to six where they expected one, and the number is a direct proxy for what a change will cost. Track it quarterly.

Try to delete something. Pick a feature you believe is unused. Attempt removal. How long it takes, and how many surprises you hit, is a measurement of coupling that no static metric gives you. If nothing can be removed, the system will only ever get more expensive.

What follows for practice

Consolidate on a schedule. Module six argued this as process; here is the cost argument behind it. The fourth date parser costs nothing to add and something every month forever.

Review for concept count, not only correctness. “This is correct, and it is the third way we do this” is a legitimate rejection, and it is the review comment most often swallowed because it feels pedantic.

Justify dependencies against a decade. Not “does this work” but “am I willing to own the migration when it is abandoned”.

Write down why, not what. The reasoning is the expensive artefact, it is the one generation does not produce, and a three-line commit message explaining a rejected alternative may be the highest-value thing you write that day.

The question that separates cheap systems from expensive ones is not “how long did this take to build”. It is “how long does it take a stranger to change it safely”, and that number is set by decisions made when nobody was measuring it.