Why lines of code are a bad measure of developer productivity
Taylor Bruneaux
Analyst
Traditional metrics, like lines of code (LOC), have long been a staple of trying to understand developer productivity. However, the reliance on LOC, whether counting total lines, source lines, or differentiating between logical Source Lines of Code (SLOC) and physical SLOC, is increasingly recognized as a flawed approach. This article explores why lines of code, in all their forms—physical line counts, logical SLOC, or even the count lines of code (CLOC)—fall short as a measure of software development productivity and alternatives to understand it better.
What are lines of code?
Lines of Code (LOC) is a common metric in software engineering. It refers to the number of lines in a software program’s source code. LOC is used to quantify the size of a software project by counting the number of lines it comprises. This measurement includes all the text in the source files, which can be divided into several categories, such as executable statements, declarations, comments, and blank lines, depending on the specific definitions and counting methods employed.
There are two primary types of LOC measurements: physical LOC and logical LOC (also known as Source Lines of Code, SLOC). Physical LOC counts every line in the source code, including blank lines and comments, giving the code base a straightforward, literal size. Logical SLOC, however, attempts to measure only the lines contributing to the software’s functionality, excluding comments, blank lines, and possibly other non-executable statements, depending on the specific methodology used.
Examples of LOC
To illustrate how LOC can vary, consider the following simple examples in different programming languages:
Python (Logical LOC):
This Python script has three logical LOCs: the function definition line, the return statement, and the print function call. Comments and blank lines, if any, would not be counted in logical LOC but would be included in physical LOC.
Def add(a, b):
return a + b
print(add(2, 3))
Java (Logical LOC):
In this Java example, there are 7 logical LOC: the class declaration, main method declaration, println statement, add method declaration, and the return statement. As with Python, comments and blank lines are excluded from logical LOC.
public class Addition {
public static void main(String[] args) {
System.out.println(add(2, 3));
}
public static int add(int a, int b) {
return a + b;
}
}
HTML (Physical LOC):
When counting physical LOC in an HTML document, every line is counted, resulting in 9 physical LOC for this example. Logical LOC doesn’t typically apply to markup languages like HTML, as they don’t contain “executable” code in the same sense as programming languages.
<!DOCTYPE html>
<html>
<head>
<title>Page Title</title>
</head>
<body>
<h1>This is a Heading</h1>
<p>This is a paragraph.</p>
</body>
</html>
Understanding LOC in context
While LOC provides a tangible measure of software size, it’s important to understand its limitations and context. The examples above demonstrate how LOC counts can vary significantly across languages and even within the same language, depending on what is considered “logical” code.
Moreover, LOC does not account for the code’s complexity, quality, or functionality, making it a somewhat crude measure of software development effort or productivity. Despite its limitations, LOC can serve as a useful starting point for assessments, provided it is used in conjunction with more qualitative metrics that consider the broader aspects of software engineering.
The misleading nature of LOC
At first glance, using LOC to measure productivity seems straightforward. More lines of code mean more output, right? This simplistic view overlooks several crucial aspects of software development.
Software engineering is inherently complex, and the value lies not just in the quantity of code but in its quality, functionality, and how effectively it solves a problem. A high LOC count does not necessarily equate to more functionality or better performance. In fact, in many cases, skilled developers achieve more with fewer lines of code.
Here are some of the most prominent issues with using lines of code to measure developer performance:
The variability across programming languages
One of the significant drawbacks of LOC measures, including physical SLOC and logical SLOC, is their failure to account for the variability across different programming languages. A task accomplished with a hundred lines of code in one language (e.g., C++) might only take a few lines in another (e.g., Python). This discrepancy makes LOC a highly unreliable metric when comparing productivity across projects or teams in different languages.
The quality over quantity paradigm
In software development, quality often trumps quantity. A smaller, well-refined code base is usually more desirable than a large, cumbersome one. High-quality code is maintainable, scalable, and bug-free. Measures like code quality, PR size, and using functional and performance cookies for web applications offer a more nuanced understanding of a developer’s contribution than merely counting lines.
Bill Atkinson famously wrote substantial portions of the Macintosh operating system with concise and efficient code. His work exemplifies how skilled developers can deliver exceptional functionality with fewer SLOC, emphasizing the importance of efficiency and effectiveness over sheer volume.
The impact of code complexity and refactoring
Code complexity and the need for refactoring further illustrate why LOC is an inadequate metric. More lines of code can lead to increased cognitive complexity, making the software harder to maintain and more prone to errors. Conversely, refactoring—restructuring existing code without changing its external behavior—often reduces the line count while improving code quality and maintainability. Measuring productivity by lines of code discourages this crucial practice.
The role of non-executable statements
LOC metrics, including the count of comment lines and blank lines, don’t distinguish between executable and non-executable statements. Comments, for instance, are essential for code maintainability but don’t directly contribute to functionality. Including these in productivity measures skews the perspective, suggesting that more comments or blank lines contribute to developer productivity, which is not the case.
Alternatives to measuring lines of code
Investing in Developer Experience (DevEx) is a superior strategy for enhancing developer productivity, moving away from traditional, quantitatively focused metrics like lines of code.
DevEx encompasses all aspects of a developer’s interaction with their work environment, including the tools, processes, and culture that enable them to perform their tasks. Unlike the simplistic and often misleading measure of LOC, focusing on DevEx offers a holistic approach that leads to sustainable improvements in productivity, quality, and job satisfaction.
Here are some of the critical tenets of developer experience that offer a strong understanding of developer productivity:
Clear direction
Providing a clear direction for development projects is essential. It helps developers understand the end goals, aligns their work with the business objectives, and reduces the time spent on unnecessary tasks. A clear direction also ensures that the team works cohesively towards a common goal, thus minimizing confusion and maximizing productivity.
Codebase experience
Improving the codebase experience involves making the codebase more understandable, navigable, and manageable. Improvement includes reducing technical debt, improving code modularity, and ensuring the codebase is well-documented. A cleaner, more organized codebase allows developers to make changes more efficiently and reduces the likelihood of introducing errors.
Cross-team collaboration
Encouraging cross-team collaboration removes silos and fosters a culture of knowledge-sharing and collective problem-solving. It allows teams to leverage diverse perspectives and expertise, leading to more innovative solutions and faster problem resolution. Collaboration tools and practices such as pair programming, code reviews, and regular cross-team meetings are vital.
Efficient processes
Streamlining processes to make them more efficient can significantly impact developer productivity. This streamlining includes optimizing build processes, easing release, and simplifying incident response. Efficient processes reduce waiting times, minimize bureaucratic hurdles, and allow developers to focus more on their core work: coding.
Learning culture
Promoting a learning culture encourages continuous improvement and adaptation to new technologies and methodologies. It involves providing resources for learning, encouraging experimentation, and recognizing failures as learning opportunities. A learning culture keeps the team updated with the latest technology and motivates developers by investing in their growth.
DevEx beats lines of code for developer productivity
Investing in Developer Experience offers a more comprehensive approach to measuring productivity than simply focusing on lines of code. This approach benefits both developers and organizations. It is a direct and concise way to improve the experience of developers.
While lines of code can offer specific definitions and quantitative data, they fail to capture the essence of developer productivity in software engineering. The complexity and variability across programming languages and the emphasis on code quality and functionality make LOC a poor stand-alone metric.
As the industry evolves, focusing on more holistic and qualitative measures like code quality, the impact of changes on the main branch, and the overall efficiency of the code base provides a better understanding of productivity. In pursuing excellence in software development, it’s clear that we must look beyond the line count to appreciate and truly measure developers’ contributions.