Lines of Code Is a Garbage Metric

TL;DR: Lines of code measures typing. It rewards bloat and duplication, punishes deletion and simplification, and was publicly humiliated as a productivity metric in 1982, when Bill Atkinson answered Apple's weekly LOC form with "-2000" after making QuickDraw six times faster by removing code. Forty years later the metric still walks among us, and AI assistants have made it strictly worse, inflating line counts while duplication climbs. Here's why LOC keeps coming back, and what to look at when someone insists on a number.

Every few years, someone in a leadership meeting rediscovers a beautifully simple idea: code is made of lines, engineers write code, so surely the engineers who write the most lines are the most productive. It's the engineering equivalent of judging chefs by kilograms of food plated. And it has been failing, publicly and hilariously, since before most of today's engineers were born.

The 1982 receipt

In February 1982, Apple's Lisa team began tracking productivity with a weekly form: lines of code written. Bill Atkinson - author of QuickDraw, the graphics engine the Mac would be built on - had just rewritten its region-calculation engine, making region operations "almost six times faster." The rewrite also removed about two thousand lines. As Andy Hertzfeld tells it on folklore.org, Atkinson thought "the lines of code metric only encouraged writing sloppy, bloated, broken code," so he wrote -2000 on the form. A couple of weeks later, management quietly stopped asking him to fill it out.

That's the whole argument, forty-four years old and undefeated: the best work in the codebase's history subtracted lines. Any metric that scores it negative isn't measuring productivity - it's measuring the opposite, with confidence.

Why LOC fails, mechanically

• It measures typing, not thinking. The hard part of engineering is deciding what to build and how; the typing is just the receipt. A day of debugging that ends in a one-line fix scores 1.
• It punishes deletion, the most valuable commit type. Removing dead code, collapsing duplication, simplifying an abstraction: all negative score. You get less of what you punish.
• It rewards bloat. Copy-paste instead of extract, verbose instead of clear, boilerplate instead of design. You get more of what you reward.
• It's incomparable across work. A line of infrastructure YAML, a line of gnarly concurrency code, and a generated migration are not the same unit; summing them is numerology.
• It's the most gameable number you own. And per Goodhart, the moment it becomes a target, it will be gamed. The SPACE research is categorical: productivity cannot be captured by any single metric, and raw activity is the weakest dimension there is.
• It can't see the work that multiplies the team. Review quality, mentoring, unblocking, the glue work that makes ten engineers a team: all of it produces approximately zero lines under the glue person's name.

AI broke it further

LOC always had a weak defense: "it's crude, but at least it correlates with something." AI assistants have now severed even that. GitClear's analysis of 623 million code changes found code-block duplication up 81%, within-commit copy/paste rising from 9.4% to 15.7% of changes, and refactoring line-moves down 70%. Code is being added at unprecedented rates and cleaned up almost never.

In an AI-assisted org, a high line count increasingly measures the rate at which future maintenance is being generated. Rewarding LOC in 2026 doesn't just misread productivity. It actively pays for the duplication your team will spend next year deleting. The engineer prompting an assistant into a 3,000-line PR outscores the one who spent the week reviewing it properly, and only one of them protected the codebase.

Why it survives anyway

Because it's countable. LOC is available in every repo, requires zero setup, produces a satisfying per-person number, and lets a spreadsheet do the thinking. That convenience is exactly the trap: the number is precise, objective-looking, and wrong. Once it lands in a dashboard, it starts quietly doing stack-ranking's job without anyone having approved a ranking system. The demand underneath ("I need visibility") is legitimate. The metric is not.

What to measure when someone insists on numbers

Point the numbers at the system, where they diagnose instead of accuse:

1. Where work waits. Review pickup, CI, deploy queues. Queue time explains more "slow team" stories than any individual ever has.
2. Whether the thing shipped, worked, and stayed working. Delivery and stability signals beat artifact counts every time.
3. How the knowledge is distributed. Knowledge concentration and load balance (who's the only person touching what) predict the failures that actually hurt, as any individual-metrics postmortem shows.
4. For people questions, use scorecards. Where a per-person view is legitimate - growth, support, recognizing what someone uniquely carries
   • use multi-dimensional, evidence-linked scorecards, never a single sortable count.

Atkinson's form asked the wrong question and got a magnificently right answer. When someone proposes counting lines, tell them the story, then hand them a better question. Not who typed the most, but where does our work wait, what does it cost, and who's quietly holding it all together? Those have answers worth acting on. The line count never did.