From Lines of Code to Developer Productivity

Does more code mean more productivity? Not really.

It’s been a common assumption for a long time now that a developer’s productivity can be measured by the number of lines of code (LOC) they write. If you look at it from a myopic view, it might make sense to think that. In the grand scheme of things, however, this is usually not the case.

Computer scientist Edsger W. Dijkstra said something interesting: “Simplicity is a prerequisite for reliability.” Frankly, he made a valid point. A McKinsey study found that teams prioritizing collaboration, problem-solving, and code quality over code count reduced product defects by 30% while delivering more value.

If LOC isn’t reliable, then what is? Let’s find out!

If you found a more visual way to accomplish a task, wouldn’t you go for it? That was the case for managers in the past. They found it easier to count LOC, generate a report, and use that number to track how much work developers were doing. They probably thought it was the best and easiest solution to track programmer productivity.

But then again, not all source code is equal. You could have a task that takes hundreds of lines in Java, which would only take a fraction of that in Python. That is because programming languages differ in coding styles, building definitions, and language definitions.
Since the amount of code can vary so much between languages, comparing LOC across teams to determine productivity didn’t make sense.

It might come as a shock to you, mainly because we just established that counting LOC isn’t reliable, but do you know there was a time when it did work?

For context, we didn’t have all these automation tools or frameworks as we do now, nor did we have reusable code modules. At this time, developers had to manually write code from scratch for every feature.

Back then, programming in languages like COBOL required extensive lines of declarations and structuring for even the most basic operations, such as opening a file. Today, the same task can be accomplished in C with just a few well-placed commands. The industry has advanced, but many companies have held onto LOC as a performance metric, even as programming paradigms have shifted.

More lines meant more functionality, so managers used LOC to estimate the time needed to complete a project and the complexity involved in the coding phase.

But now, we have external modules and scripting languages that speed up development. A feature that would have taken millions of lines years ago can now be implemented with auto-generated and hand-written code in a combination of files. Now, we see companies moving past the old way of total reliance on absolute code count.

It’s a fact that no skilled developer would want to waste their time on unnecessary code duplication or poor code readability. Some people think that a developer writing twice the amount of code shows that a good job was done, but that isn’t ideal.

Image description: Why more code doesn’t always mean better code

Writing a concise and structured source code is way more valuable than just writing more of it.

To give you a clearer picture, look at this function written in a verbose way:

def is_even(number):

    if number % 2 == 0:
      return True

    else:
      return False

Take a look at the same function, but this time expressed in a much simpler way:

def is_even(number):

    return number % 2 == 0

You can see that choosing to use LOC as a performance metric promotes redundant code. And what happens to companies that focus on LOC instead of code quality? They end up with bloated systems and slower releases or even costly refactoring.

David A. Wheeler’s research on code counting tools like the SLOCCount (source lines of code count) further proves this point. His findings highlighted how code complexity, maintainability, and adherence to coding standards matter far more than the volume of code written.

As a team lead, you must know what makes a productive developer. It is not the developer that writes the most code lines, but it is the one that:

• Solves the problems
• Prevents issues before they happen
• Builds stable systems

You now know that writing fewer lines of source code is better than writing hundreds of lines, which simply adds code complexity. When the developers on your team write clean, structured code, it always makes the development faster and usually reduces the number of bugs in the codebase.

Most of the time, removing bad code is more valuable than adding new features. Having a codebase experience full of commented-out code and poor coding styles makes it harder to maintain and slows progress.

Productivity isn’t just about being able to work alone; it’s actually about collaboration, mentorship, and code reviews.

“The best teams do not just write code. They discuss it, test it, and make it better.“

Senior engineers are known to write less but make bigger contributions through architecture and technical decisions for the entire project.

Companies are now moving past LOC because they have realized that progress is more about impact than absolute code count. They now know that writing more code doesn’t always mean better results. The teams are now more bent towards:

• Code quality
• How quickly useful work gets delivered
• Collaboration

This is good because teams now have better ways to measure developer productivity. Let’s look at them.

Quality over quantity

Teams understand now that a high LOC count doesn’t guarantee better software. When you have well-structured and maintainable code, reading, testing, and updating becomes easier. Blank lines, source lines, and logical lines only show the code volume, not its readability, maintainability, or impact on the project.

A developer who removes redundant code or refactors bad code contributes more to a codebase than one who simply adds more lines of source code. In his book Refactoring: Improving the Design of Existing Code, Martin Fowler explains how restructuring code makes it easier to maintain and adapt over time. Metrics such as pull request (PR) feedback, bug reports, and refactoring efforts provide a better picture of a developer’s impact.

Pull requests, lead time, and code changes

Rather than tracking absolute code count, physical entity count, or bloat factor, teams focus on pull request size, frequency, and lead time. These metrics show how developers contribute to the code base.

A large, slow-moving PR can signal bottlenecks, while smaller, frequent PRs help teams release updates faster. Code deletions, code duplication fixes, and improvements are just as important as new lines since removing commented-out code and poorly structured code modules makes systems easier to maintain.

Teams also compare archives, binary and zero-sized files, and millions of lines of source code to track changes. However, these methods still fail to capture code readability, external modules, and the contributions of experienced developers.

The developer experience factor

Developers do better work when they have clear goals, a structured codebase, and fewer distractions. Productivity is not about typing faster but working in an environment that allows engineers to write better code.

Many companies now invest in better tools, well-defined coding standards, and structured project analyzers instead of using LOC-based metrics. Google, Microsoft, and Meta no longer use LOC to measure programmer productivity because they understand that software metrics should account for problem-solving, architecture decisions, and coding styles rather than just the volume of code.

By shifting focus from counting code lines to assessing how developers contribute to software projects, companies avoid poor productivity measures and focus on what actually moves development forward.

Software development is not about how many lines of code a developer writes per day; it is about what those lines accomplish. The best engineers do not just add to a codebase; they make it simpler, cleaner, and easier to maintain. Measuring developer productivity by absolute code count or coding standards misses the bigger picture.

Companies like Google and Microsoft have moved past LOC-based tracking, and Milestone is helping teams do the same. Rather than tracking code complexity by numbers alone, Milestone helps teams identify meaningful contributions, reduce bottlenecks, and deliver better project outcomes.

Stop tracking lines of source code. Start measuring developer productivity with Milestone.