Why lines of code is not the right productivity metric

Lines of code measures how much text your engineers typed. It says nothing about whether the product got better. The two often move in opposite directions.

If you run a company and can’t read code, the metric is tempting. It’s a number. GitHub shows it to you for free. It even looks fair, because it treats everyone the same way. This post explains why the number misleads you, what it does to a team once they know you’re watching it, and what to look at instead.

What “lines of code” means

Software is text. A product like yours is made of thousands of text files, and each instruction in them sits on its own line. Count the lines and you have lines of code, often shortened to LOC.

Tools report it two ways. The total size of the codebase, or the lines each person added and removed this week. Managers reach for the second, because it looks like output per worker.

There’s an old line about this, usually credited to Bill Gates: measuring programming progress by lines of code is like measuring aircraft building progress by weight. A heavier plane is not a better plane. Usually it’s a worse one.

The engineer who reported minus 2,000 lines

In 1982, Apple’s Lisa team started asking engineers to report their lines of code every week. Bill Atkinson, who wrote the graphics code the Mac was built on, had just rewritten one core routine. It ran six times faster. It also had fewer lines than before.

When the form asked how many lines he’d written, he thought about it and wrote -2000. Andy Hertzfeld, another early Mac engineer, tells the story: “after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied.”

The metric scored a week of excellent work as a negative number.

Why the number misleads

Good work often deletes code

Some of the most valuable things an engineer does make the codebase smaller. A fix that removes a special case. A rewrite that folds three copies of the same logic into one. Less code means fewer places for bugs to hide and less for the next engineer to read before they can change anything.

The computer scientist Edsger Dijkstra made the point in a 1988 paper: “if we wish to count lines of code, we should not regard them as ‘lines produced’ but as ‘lines spent’.”

Think of code the way you think of headcount. You don’t celebrate having more of it. You celebrate what it gets you.

The same feature can take 50 lines or 500

Give two engineers the same task. One writes 50 careful lines. The other writes 500 that do the same job, more slowly. Lines of code says the second one did ten times the work.

The gap isn’t always skill. Some programming languages need far more lines to say the same thing. Some teams format their code so one instruction spreads across five lines. None of this changes what the customer gets, and all of it changes the count.

People produce what you count

Once a team knows a number is being watched, the number goes up. Nobody has to cheat for that to happen. People do what the scoreboard rewards.

With lines of code, the scoreboard rewards:

• Copying and pasting instead of reusing what already exists.
• Leaving old code in place, because deleting it counts against you.
• Spreading work across more lines than it needs.
• Skipping the cleanup that would make next month’s work faster.

Economists call this Goodhart’s law. Turn a measure into a target and it stops measuring anything.

AI made it worse

Ask your engineers whether they use an AI coding assistant. The answer is almost certainly yes. Those tools produce hundreds of lines in the time it takes to describe the problem. Typing was never the hard part of the job, and now it’s close to free.

Google’s DORA research group looked at what that did to teams in its 2024 State of DevOps report. AI adoption “significantly increases individual productivity, flow, and job satisfaction.” It also “negatively impacts software delivery stability and throughput.” More code, written faster, and more of it failed once it shipped.

We covered the same shift in how to know if your dev team is working well. Once output gets cheap, output tells you less.

What the people who study this say

Google’s own book on how it builds software, Software Engineering at Google, has a chapter on measuring productivity. It dismisses the metric in one sentence: “Clearly, lines of code (LOC) won’t do.”

Researchers from Microsoft and GitHub reached the same place from a different direction. Their SPACE framework opens by saying developer productivity “cannot be measured by a single metric or dimension.” Activity, which is what lines of code counts, is one of five dimensions, and the only one the metric touches.

What to look at instead

You want to know whether the team is productive. The honest answer is that no single number tells you. A few questions get close, and none of them need you to read code.

• Did what they said would ship, ship? Compare the plan from the start of the month with what customers can use now.
• What changed for customers this week? If the team can’t say it in plain words, that’s the first problem to fix.
• What came back? Fixes to last month’s work show up as this month’s activity. Lines of code counts them as progress twice.
• How early does bad news arrive? A team that says “this will slip” in week two is working well, whatever the counts say.

The engineering update format we recommend leaves the counts out for exactly this reason.

If you want a number, use the DORA metrics. They measure how fast and how safely the team ships, which is a real thing, and they’re measured for the team rather than per person. They still won’t tell you what shipped.

The raw material for the plain-words answer already exists. Your repository records every change, who made it, and when. What’s missing is the translation into a sentence a board member can read. DevSummary reads that history and writes the update for you, on a schedule, scoped to a project or a team. Nobody counts anything.

Common questions

Is lines of code ever useful?

As a measure of size, yes. A change that touches 3,000 lines is harder to review and more likely to break something than one that touches 30. That’s a risk signal, and a good engineering lead watches it. Treat it as a warning light, never as a score.

Are commit counts any better?

Same problem, one level up. A commit is one saved batch of changes, and engineers differ on how big a batch should be. Ten small commits and one large one can be the same work. Counting them tells you about habits, not progress.

How do I compare two engineers without a number?

Don’t try to rank them from a dashboard. Ask their team lead what each person shipped that customers noticed, and how often their work came back with problems. The team management practices we recommend for non-technical founders cover what to measure at the team level instead.