Lines of code as a measure of anything

1960s onwardsWhat it was used for

Two different jobs, which is the source of most of the confusion. As an input to estimation models, where a predicted size is used to predict effort. And as a measure of what somebody produced.

The first use is defensible with care. The second is the one that produced the folklore, and it is the one that keeps returning under new names.

Why it cannot compare across languages

A line of assembly and a line of a modern high-level language differ by orders of magnitude in what they accomplish. A configuration file may replace a thousand lines of either.

So the measure ranks languages rather than people, and a team that adopts a more expressive language records a collapse in productivity by the only measure being kept.

Why it punishes the right behaviour

Deleting code that is no longer needed improves a program and reduces the number. Replacing a long implementation with a shorter correct one reduces it. Finding that an entire component can be removed reduces it most of all.

A well-known recollection from a personal computer project of the early eighties has an engineer reporting a large negative number on a weekly productivity form after removing thousands of lines while making the system faster. It is an anecdote, retold decades later, and it endures because everybody recognises the situation.

1988What a critic said better

A well-known note argued that if lines are to be counted at all they should be regarded not as something produced but as something spent: the ledger entry belongs on the other side.

That reframing is the whole argument in one move. Code is the cost of having the behaviour, not the product, and a measure that treats it as output has the sign wrong.

1979 onwardsThe replacement that was tried

A method counting units of delivered function rather than lines, derived from inputs, outputs, files and interfaces, and therefore independent of language.

It works, and it requires trained judgement, takes time, and produces numbers that two trained counters do not fully agree on. Which is why it is used mainly where a contract requires it, and why the cruder measure survived.

2010s onwardsWhat is measured now instead

The current answer measures the delivery system rather than the person: how often changes reach users, how long a change takes to get there, how often a change causes a failure, and how long recovery takes.

Those are properties of an organisation and they are meaningful at that level. Applied to individuals they become the same mistake in newer clothing, and they are being applied to individuals in some places already.

Where a line count is still the right tool

Measuring the size of a change, as a rough signal that a review will be poor. Estimating the scale of a migration. Noticing that a file has grown past what anyone can hold in their head.

In every one of those the number describes an artefact rather than a person, and nobody's assessment depends on it, which is exactly the condition under which a proxy stays honest.

What a size measure is legitimately for

Estimation models take a predicted size and produce a predicted effort, calibrated against past projects. Used that way the number is an input to a comparison between similar things, and nobody is being assessed by it.

The difficulty is that predicting the size is nearly as hard as predicting the effort, which the entry on estimates covers. So the model converts one uncertain quantity into another, usefully where the past projects genuinely resemble the new one and not otherwise.

present dayThe version of this that is current

Counting merged changes, closed items, or activity in a repository. Each has exactly the properties that made the line count attractive: computable without cooperation, comparable between people, and unrelated to whether anything valuable happened.

The response is the same as it was: the measure is fine as a description of an artefact and becomes fiction the moment somebody's assessment depends on it.

The thing it cannot see at all

The code that was not written. A component removed by noticing it was unnecessary, an integration avoided by choosing a simpler approach, a feature talked out of the specification.

Those are among the most valuable acts available to a practitioner and they register as an absence in every measure of output, which is the same structural blindness described at the end of the part on practice.

Where the sign is right

One counting practice inverts it usefully: tracking how much code a system carries, as a liability to be watched rather than an asset to be accumulated.

Under that reading a growing total is a cost being taken on, and a shrinking one is a debt repaid, which is the same number read the way the criticism in this entry recommends.

Why it keeps coming back

Because it is available. It requires no judgement, no configuration and no cooperation, and it can be computed for an entire organisation by one person in an afternoon.

Every measure with those properties will be adopted somewhere regardless of what it means, which is the general observation this part of the document exists to make.

What we cannot verify

The estimation models, the function counting method and the criticisms are published. The negative-lines story is a recollection published long after the event by a participant, and is repeated here as such. Claims about the effect of any measurement scheme on behaviour come mostly from single organisations and are not reproducible.