If you're still using lines of code to measure developer productivity, you're likely getting a misleading picture. This article explains why LOC fails as a metric and what high-performing engineering teams measure instead.
In the early days of software engineering management, we didn't have good data. So we counted what we could see: Lines of Code (LOC). It seemed logical. A builder lays bricks; a coder writes lines. More lines equals more work, right?
Wrong. In fact, often the opposite is true.
Why Lines of Code Fails as a Productivity Metric
Junior engineers solve problems by adding code. Senior engineers solve problems by removing it.
If Developer A writes a 500-line function to parse a CSV, and Developer B imports a library and does it in 5 lines, who was more productive? Developer B shipped faster, introduced fewer potential bugs, and created less technical debt to maintain. But on a LOC dashboard, they look lazy.
What to Measure Instead of Lines of Code
Instead of raw volume, we need to look at the nature of the contribution.
1. Complexity and Churn
Velocinator looks at "Impact" by weighing changes based on the file's history and complexity. Editing a core authentication module that hasn't been touched in months is higher impact than updating a CSS color variable or auto-generating a migration file.
2. Refactoring Ratio
Healthy codebases breathe. They expand and contract. We track deleted lines as a positive metric. A PR that removes 2,000 lines of dead code is a massive win for the team's long-term velocity.
3. Traceability
Does this code solve a user problem? By linking PRs to Jira tickets or GitHub Issues, we verify that the code serves a business purpose. High activity without traceability often indicates "gold plating" or unplanned work.
Use Metrics for Questions, Not Answers
Never use data to rank developers. Use it to ask better questions.
- "I see you wrote a huge amount of code this week but merged no PRs. Are you stuck on a massive refactor? Can we break it down?"
- "Your impact score is low, but you've reviewed 30 PRs. You're acting as a force multiplier for the team—thank you."
Context is king. Data is just the conversation starter.
For more on using metrics responsibly, see our guide on using metrics for growth, not ranking. And to understand the broader picture of engineering measurement, read about measuring velocity without losing quality.
Frequently Asked Questions
- Why is lines of code a bad metric?
- Lines of code measures volume, not value. Senior engineers often solve problems by removing code, not adding it. LOC incentivizes bloated solutions and penalizes elegant, maintainable ones.
- What should I measure instead of lines of code?
- Focus on impact-weighted contributions (complexity and file history), refactoring ratio (deleted lines as a positive signal), and traceability (linking code to business outcomes via Jira tickets or GitHub Issues).
- How do I measure developer impact without LOC?
- Use composite metrics that weigh the complexity and criticality of changes. Editing a core authentication module is higher impact than updating a CSS variable. Tools like Velocinator calculate this automatically.
