Is it a false assumption that writing more code, making more code changes is better? Let’s see.
As the software development industry continues to evolve, the need for measuring productivity has increased as well. Managers often use metrics such as lines of code or commit count to gauge the performance of developers. However, using these metrics can be counterproductive, and often leads to negative consequences for both developers and the company. In this post, we will discuss why line of code or commit count is a bad metric, and what should be the metric a developer is measured on instead.

Line of Code and Commit Count: A Flawed Metric
One of the most common metrics used to measure a developer’s productivity is the number of lines of code they produce. The idea behind this metric is simple: the more code a developer writes, the more productive they are. Similarly, commit count is another metric that is used to measure productivity. A commit is a snapshot of code that a developer makes to a code repository. The more commits a developer makes, the more productive they are presumed to be.
However, both of these metrics suffer from several flaws. Firstly, the number of lines of code or commits a developer produces does not take into account the quality of the code. A developer could write a thousand lines of code, but if they are poorly written, buggy, and difficult to maintain, they are not productive at all. Similarly, a developer could make hundreds of commits, but if they are not adding any value to the project, they are not being productive.
Secondly, these metrics do not consider the context of the project. The number of lines of code or commits required for a small project is vastly different from that of a large, complex project. A developer working on a small project could write a few hundred lines of code and be done with it, while a developer working on a larger project could write thousands of lines of code, but still be far from completing the project. Comparing the productivity of these two developers based solely on lines of code or commit count is not a fair assessment.
Thirdly, these metrics can lead to unhealthy competition among developers. When developers are measured based on the number of lines of code or commits they produce, they may feel pressured to write more code than necessary, even if it means compromising on quality. This can lead to a culture where developers are encouraged to prioritize quantity over quality, leading to technical debt, poor code maintainability, and increased project costs in the long run.
A Better Metric for Measuring Developer Productivity
So, if lines of code or commit count is a flawed metric, what should be the metric a developer is measured on instead? The answer lies in measuring the value a developer adds to the project. The value a developer adds is a combination of several factors, including the quality of their code, their ability to meet project goals, their collaboration with team members, and their contribution to the project’s overall success.
Measuring value can be tricky, but some of the ways to measure it include measuring the impact of a developer’s code on the project, the number of bugs they fix, the number of customer tickets they resolve, and the feedback they receive from team members and stakeholders. These metrics provide a more comprehensive view of a developer’s performance and their contribution to the project’s success.
Another important metric to consider is the developer’s ability to learn and grow. The technology landscape is constantly evolving, and developers who can learn and adapt to new technologies are more valuable to the company. Measuring a developer’s ability to learn new skills, their participation in training programs, and their involvement in open-source projects can provide insights into their potential to grow and contribute to the company’s long-term success.
In conclusion, lines of code or commit count is a flawed metric for measuring developer productivity. Instead, companies should focus on measuring the value a developer adds to the project and their ability to