Do Not Measure Productivity by Lines of Code

For programmers, team leads and product managers. Every technical term gets a short explanation.

Figures come from public sources listed at the end; many were published by technology companies, so read them with care. The characters "Hung" and "team Plum" are illustrations rebuilt to be easy to picture, not real people.

---

Quick summary#

• Lines of code measures what was written, not what was delivered. Good solutions are often shorter, and deleting surplus code is a contribution.
• When a number becomes a target it gets distorted (Goodhart's law). People will make the number look good, even by making the product worse.
• In the AI era it is even less meaningful: AI writes thousands of lines in seconds, so the count rises while value may not.
• Measure by team and by outcome: lead time, change failure rate, review wait, rework, satisfaction.
• Use metrics as trends, pair speed with quality, and do not rank individuals with them.

---

Hard words, plain meaning#

---

1. The minus-2000-lines story#

In early 1982, a manager on Apple's Lisa team wanted to measure engineer productivity by lines of code written each week, and everyone had to fill in a form. As Andy Hertzfeld tells it on folklore.org, Bill Atkinson was then optimizing the region-handling part of the QuickDraw graphics library. He replaced it with a simpler algorithm that made region operations about six times faster and, as a by-product, removed about 2,000 lines of code.

When he reached the form, he wrote -2000. As the story goes, a few weeks later they stopped asking him to fill it in.

This is an anecdote, retold through several sources, so do not treat each detail as exact. But its point stands: the best work of that week made the line count go down.

---

2. Why lines of code mislead#

There are three simple reasons.

1. It measures text, not results. Users do not pay for lines of code. They pay for their problem being solved.
2. Less is often better. Less code means fewer places for bugs, less to read and less to maintain.
3. It is easy to game. When lines are the target, the cheapest way to raise them is to write long, split things pointlessly, or copy and paste.

The last is Goodhart's law: when an indicator becomes a target it stops being a good indicator. Lines of code, commit counts and story points are classic examples.

---

3. Illustration: team Plum and the leaderboard#

An illustrative example with rebuilt characters.

Team Plum has four people. The manager starts posting a "lines of code per week" board in the shared channel, with good intentions of creating motivation.

• Week 1. Hung writes 900 lines. Lan writes only 120 because she spent the week chasing a hard bug customers were complaining about.
• Week 3. Lan sees her name at the bottom. She stops cleaning up old code and turns to adding small features.
• Week 6. Hung uses AI to generate 3,000 lines, many of them copies of each other. The board looks better, but review time doubles and two bugs slip into a release.
• Week 8. The team understands the board does not say what the manager needs to know, but everyone has already changed behavior.

The point is that behavior changes faster than the flaw in the measure is noticed.

---

4. In the AI era the problem is heavier#

AI makes producing code cheap, so every measure based on code volume balloons.

• Faros AI data (July 2025, over 10,000 developers in 1,255 teams) found teams using AI heavily merged about 98% more changes, each about 154% larger, with review time per change up about 91%. It is data from a vendor of measurement tools, a correlation, and I have read the summary.
• METR's study (July 2025) of 16 experienced developers found them about 19% slower with early-2025 AI tools, though they believed they were about 20% faster. The sample is small and tools have changed, but it shows the feeling of speed and real speed can diverge.

Together they suggest that activity numbers (lines, commits, PRs) and delivery numbers can come apart. Measuring activity in the AI era is like measuring a car's speed by wheel revolutions while the car is skidding.

---

5. What to measure instead#

Two widely used frameworks, and both stress the team and many dimensions.

DORA, four delivery metrics

SPACE (2021) treats productivity as five dimensions: satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. Its core argument is that no single metric is enough, and optimizing one dimension often drags another down.

Both are for looking at teams and systems. Using them to score individuals misses the point, because most variation comes from process and tools, not from single people.

---

6. A starter metrics board for a small team#

Begin with five metrics, record them weekly or monthly, and watch the trend.

Pair them. Every speed metric needs a quality metric beside it. A shorter lead time with a rising failure rate is not progress.

---

7. How to use them without harm#

1. Measure the team, do not rank people. Use them to ask "where does our system get stuck", not "who is weakest".
2. Watch trends, do not set hard targets. Hard targets breed games.
3. Be open about how and why you measure. The team needs to know what the numbers are for.
4. Ask people before trusting a number. A 15-minute conversation is often clearer than a dashboard.
5. Review the measures each quarter. Measures need maintenance like code.

---

8. Talking to a manager#

If a manager wants to use lines of code, start from their need, not from a rebuttal:

• "You want to know whether the team delivers steadily and safely, right?"
• "I suggest two metrics: lead time and post-release failure rate. We track the trend for three months."
• "I have a short story about an engineer who wrote minus 2000 lines. What do you think it says?"

The goal is to change the question, not the person.

---

9. A balanced view#

• Lines of code are not entirely useless. They show the size of a change and help decide how to review it (a 3,000-line change needs splitting). Use it as a warning, not a score.
• Other metrics get gamed too. Commit counts, story points, even lead time can be distorted. No metric escapes Goodhart's law, some are just better.
• Measuring is still needed. Measuring nothing is a poor choice as well. The task is to choose the right thing and the right use.
• The data is limited. Most writing on measuring productivity comes from tool vendors or blogs. I have not found independent data showing that any single metric predicts productivity well.

---

10. Conclusion#

Lines of code are easy to count, so they get used a lot. But they measure something unimportant, and in the AI era they measure something almost free. Measure the team's outcomes: delivering fast, delivering safely, little rework, and a team that still wants to work together.

A small step today: pick two outcome metrics from the table in section 6, record the last four weeks, and present the trend at your next meeting.

---

References#

• Negative 2000 Lines Of Code, folklore.org (Andy Hertzfeld)
• The SPACE of Developer Productivity, ACM Queue (2021)
• DORA 2025: State of AI-assisted Software Development
• Faros AI: AI productivity, lab versus reality
• Simon Willison on the METR productivity study
• Related posts in this blog: IT teamwork in the AI era, Reviewing AI-written code, Three hours with an AI agent on a real project