Why Measuring Lines of Code Is Worse Than Nothing

A VP of Engineering at a Series C startup told me last year that he tracked "lines of code per developer per sprint." He said it with pride, like he'd cracked the productivity code.

That company lost four senior engineers in six months.

Lines of code (LoC) is the cockroach of engineering metrics. It keeps coming back no matter how many times the industry kills it. So let me be unambiguous: measuring lines of code as a productivity indicator is worse than measuring nothing at all. At least "nothing" doesn't actively incentivize bad behavior.

# The Obvious Problems

Let's start with what everyone already knows, then get to the stuff that actually ruins teams.

More code isn't better code. The best solution to a problem is often deleting code. I once refactored a 3,000-line module into 400 lines. The result was faster, more readable, and had fewer bugs. Under a LoC metric, I'd have a negative productivity score for the best work I did that quarter.

Languages vary wildly. 100 lines of Python does what 500 lines of Java does. Are Python developers 5x more productive? Of course not. But LoC says they're 5x less productive because they wrote fewer lines.

Generated code inflates numbers. Run a scaffold command and you've "written" 2,000 lines in 30 seconds. Add a dependency and your lockfile gains 10,000 lines. Import a proto definition and auto-generate types. None of this is productive work.

These are obvious. What's less obvious is the behavioral damage.

# The Real Damage: Incentive Corruption

When you measure lines of code, developers unconsciously (and sometimes consciously) change how they work. I've watched it happen at three different companies.

Developers stop refactoring. Refactoring almost always reduces line count. If reducing lines hurts your metric, you stop doing it. Technical debt compounds. Six months later, the codebase is bloated, fragile, and slow. But everyone's LoC numbers look great.

Developers avoid reuse. Writing a utility function that replaces 200 lines scattered across 15 files is one of the most valuable things a developer can do. Under LoC tracking, you just deleted 200 lines and added 20. Net negative. So developers copy-paste instead of abstracting. The codebase becomes a maze of duplicated logic.

Developers avoid code review. Time spent reviewing someone else's code produces zero lines of code. Under LoC metrics, reviews are pure cost. So developers rubber-stamp reviews to get back to "producing." Bugs ship. Quality drops. Incidents increase.

Developers pad code. I wish I were making this up. I've seen developers add unnecessary variable assignments, break one-liners into five lines, and write verbose comments that restate what the code already says. All to hit their LoC targets. This isn't malice. It's rational behavior in response to a broken incentive.

# The Contrarian Take: Negative Lines Are the Real Signal

If you insist on looking at lines of code (and I'd rather you didn't), flip the metric. Track lines removed per sprint. Celebrate the developer who deletes the most code while maintaining functionality.

The best engineering work I've ever done was deleting things. Removing a dead feature that nobody used but everyone was afraid to touch. Replacing a hand-rolled caching layer with a well-tested library. Simplifying an over-engineered abstraction back to straightforward code.

A team where lines of code are going down while feature delivery stays constant is a team doing excellent engineering work. They're simplifying, abstracting, and paying down debt. A team where lines are going up faster than features is accumulating complexity.

# The Stealable Framework: The Value Ratio

Instead of LoC, try what I call the Value Ratio. It takes five minutes to calculate and tells you more about productivity than any line count ever could.

Value Ratio = Customer-Facing Features Shipped / Total PRs Merged

Track this weekly. A healthy ratio is 0.3-0.5 (30-50% of PRs deliver direct customer value). Below 0.2 means too much of your effort goes to infrastructure, bugs, and internal tooling relative to value delivery. Above 0.6 is suspicious and usually means you're cutting corners on maintenance.

This isn't perfect. No single metric is. But it measures something actually useful: what percentage of your engineering effort translates to customer value?

Combine it with PR size distribution (aim for a median under 200 lines changed) and review turnaround time (aim for under 4 hours). These three numbers together give you a healthier picture of team productivity than LoC ever could.

# What to Do Instead

If you're currently tracking lines of code, here's your migration plan:

1. Stop displaying LoC metrics immediately. Don't announce it. Just remove them from dashboards and reports.
2. Replace with cycle time. Measure the time from first commit to production deployment. This captures what you actually care about: how fast work flows through the system.
3. Track PR size distribution. Not to measure productivity, but to encourage small, reviewable changes. Research consistently shows that PRs under 200 lines get reviewed faster, have fewer bugs, and ship sooner.
4. Ask your developers. Survey quarterly. "What slows you down the most?" The answers will surprise you. It's never "I don't write enough lines of code." It's usually meetings, unclear requirements, slow CI, or waiting for reviews.

The goal of measurement isn't to rank developers. It's to identify and remove friction. Lines of code measures neither friction nor value. It measures typing speed with extra steps.

Kill the metric. Your team will thank you.