Why is LoC bad as an individual metric of productivity?

Measuring software development productivity isn’t easy. Many organizations and managers have tried using lines of code (LoC) to measure developer output. At first, this might seem logical since more code should mean more work, right?

However, relying on LoC as a productivity metric is misleading. Writing more code doesn’t always mean better results, and in many cases, less code is actually more efficient.

What are lines of code (LoC)?

Lines of code (LoC) refers to the number of lines written in a program, including:

• Executable code (functions, loops, and logic implementations)
• Comments and documentation
• Whitespace and formatting lines

Many organizations have historically used LoC as a productivity metric, assuming that writing more code signifies higher efficiency.

The problem with using LoC as a productivity metric

1. Quantity over quality

A higher number of lines does not equal better software. Consider these two scenarios:

• Developer A writes 500 lines of repetitive, inefficient lines of code per day.
• Developer B writes 100 lines of optimized, well-structured code that achieves the same functionality.

Which one is more productive? Developer B is delivering more value with fewer lines. Prioritizing LoC may encourage bloated, unnecessary code instead of clean, maintainable solutions.

2. Discourages code optimization and refactoring

One key principle of good software development is writing fewer lines of better code. Refactoring is often used to improve code performance, readability, and maintainability. In most cases, refactoring reduces LoC significantly.

So, if developers are judged based on the number of lines they write, they may avoid necessary refactoring efforts to maintain a high LoC count.

3. Ignores complexity and problem-solving skills

Writing software isn’t just about adding lines but solving problems. Consider the following:

• A complex algorithm may require only a few lines of code but takes days of research and testing.
• A developer debugging an issue might remove hundreds of unnecessary lines to improve efficiency.

LoC does not capture the thought process, problem-solving, or debugging efforts that go into software development.

4. Penalizes framework and library usage

Modern software development involves using frameworks, libraries, and APIs to streamline development and improve efficiency. A developer who writes concise, efficient code using libraries might produce fewer lines than one who writes everything from scratch. However, the former is more efficient and follows best practices.

5. Creates unhealthy competition

If developers are evaluated solely based on LoC, they may feel pressured to:

• Write more lines than necessary to appear productive.
• Avoid code reviews and collaboration to keep LoC numbers high.
• Resist deleting redundant code, which leads to technical debt.

Such competition fosters a toxic work environment rather than encouraging meaningful contributions.

What are better metrics for developer productivity?

Since LoC is an inadequate metric, what should organizations use instead? Here are better alternatives:

1. Code quality and maintainability

Instead of counting lines, focus on how well the code is written:

• Does it follow coding standards?
• Is it maintainable and scalable?
• Does it have clear documentation?

2. Feature completion and impact

Measure productivity based on actual contributions:

• How many features or bug fixes were delivered?
• How impactful were those changes to the software?
• Did the developer contribute to performance improvements?

3. Peer code reviews

Encouraging a culture of code reviews ensures quality and collaboration. Metrics like number of successful pull requests, constructive feedback received and given, and engagement in team discussions are far more valuable than counting lines of code.

4. Issue resolution speed

Tracking how quickly and effectively a developer resolves issues provides a realistic measure of productivity. Solving critical bugs in a few lines of code is often more impactful than writing hundreds of new lines.

5. Developer satisfaction and collaboration

A productive developer is not just one who writes a lot of code but collaborates effectively and enjoys their work. Metrics like team collaboration and contributions, participation in technical discussions, and overall job satisfaction provide a holistic view of developer productivity.

Conclusion

LoC is an outdated and misleading metric for measuring software development productivity. It encourages bad coding practices, ignores problem-solving efforts, and discourages refactoring. Instead, organizations should focus on code quality, problem-solving skills, feature completion, and collaboration to effectively measure developer contributions.

Evaluating developers should be about impact, not just output. So, let’s move beyond LoC as a metric and foster a more meaningful approach to software engineering.