Why Lines of Code Is the Worst Engineering Metric Ever Invented
Lines of code (LOC) is a terrible metric because it measures typing, not value delivered. Every competent engineering leader knows this, yet LOC persists because it's easy to measure—not because it's useful.
The Core Problem: Volume ≠ Value
Here's the fallacy:
Assumption: More lines of code = more productivity = more value delivered
Reality: More lines of code = more code to maintain, more bugs, more complexity
Software isn't construction. You don't get paid by the brick.
Example: Two Developers, Same Week
Developer A
- • Wrote 2,000 lines of new code
- • Added 3 new API endpoints
- • Shipped nothing to production
Developer B
- • Deleted 500 lines of legacy code
- • Refactored service (200 clean lines)
- • Unblocked 3 PRs with reviews
- • Shipped 4 features to production
Who was more productive? By LOC: Developer A (+2,000). By reality: Developer B (shipped 4 features, reduced complexity).
What LOC Actually Incentivizes (All Bad Things)
1. Writing Verbose Code
If you're measured on LOC, why write concise code when you could write verbose code and score higher?
Same outcome. 5x the lines. Higher "productivity."
2. Avoiding Refactoring
Found a 300-line function that could be 100 lines? If measured by LOC, refactoring looks like negative productivity (-200 lines). LOC penalizes improving the codebase.
3. Copy-Pasting Instead of Abstracting
Need similar logic in 3 places? Write a reusable function (50 lines) or copy-paste 3 times (150 lines)? LOC prefers copy-paste. LOC rewards technical debt.
4. Avoiding Code Deletion
Deprecating an old API? Remove 2,000 lines of unused code for a cleaner codebase. LOC impact: -2,000 lines = negative productivity quarter. LOC punishes code hygiene.
5. Adding Unnecessary Features
Building an MVP? LOC incentivizes adding every edge case upfront, over-engineering abstractions, and gold-plating features nobody asked for. Why ship simple when you can ship complex and get more lines?
What LOC Can't Tell You (Everything That Matters)
LOC is a lagging indicator of activity, not a leading indicator of value.
What to Use Instead of LOC
Pull Request Metrics
Track the unit of delivery, not the unit of typing.
- • Time to merge: How fast do PRs go from open → merged?
- • Time to first review: Are PRs sitting idle?
- • Review cycles: How much rework happens?
- • PR size distribution: Are we shipping small or batching?
Deployment Frequency (DORA)
How often does code go to production? This is the ultimate outcome metric.
- • Elite: Multiple times per day
- • High: Once per day to once per week
- • Low: Less than once per month
Cycle Time
Time from first commit to production deploy. Measures actual delivery speed, not typing speed.
"Measuring programming progress by lines of code is like measuring aircraft building progress by weight."
The PRPulse Alternative
PRPulse doesn't track lines of code. Ever.
Instead, we track:
- Time to merge (cycle time)
- Time to first review (approval latency)
- Review cycles (rework)
- PR size distribution (are you batching?)
- Deployment frequency (actual shipping)
- Review participation (who is unblocking?)
These metrics measure velocity, not volume.