Should you use Lines of Code (LOC) to measure coding productivity?

How to evaluate programmers

What are the pros and cons of using Lines of Code (LOC) as a measure of programmer productivity? Should you use it? Are there alternatives?

Read on to find out.

Lines of Code (LOC), sometimes also known as Source Lines of Code (SLOC), is a software metric that measures the number of lines in a program’s source code. While it has been used as a measure of programmer productivity, its effectiveness and accuracy are subjects of debate.

What are the pros and cons of using LOC as a metric for programmer productivity?

Pros

• Simplicity: LOC is easy to measure and understand. It provides a quantifiable value that can be compared across different projects or developers. LOC can also be measured automatically and aggregated into data visualizations easily.
• Estimation: LOC can be used as a rough estimate for project size and complexity, which can help in planning and resource allocation. There are many caveats, but roughly more lines imply bigger and more complex projects.
• Historical data: LOC can be used to analyze trends in software development over time, providing insights into the evolution of programming languages, coding practices, and development methodologies.

Cons

• Misleading indicator: LOC does not necessarily reflect the actual functionality or complexity of the software. A program with fewer lines of code can be more efficient and better designed than one with many lines. I often try to reduce the lines of my code in an attempt to make it better.
• Encourages poor coding practices: Focusing on LOC as a productivity metric can incentivize developers to write verbose, redundant, or unnecessarily complex code to inflate their numbers.
• Ignores code quality: LOC does not account for factors such as readability, maintainability, and extensibility, which are crucial aspects of well-written software. And often code that is high in LOC, is low in these other respects.
• Difficulty in comparing across languages: Different programming languages have varying levels of abstraction and syntax, making it challenging to compare LOC between projects written in different languages. For example, Python code is likely to be far more compact than Java code that does the same thing.
• Disregards other important tasks: Software development involves more than just writing code. Activities like testing, debugging, documentation, and collaboration are essential but not captured by LOC.

On balance, while LOC can provide some insights into software development, it is not an accurate or comprehensive measure of programmer productivity. It is essential to consider multiple metrics and factors when evaluating developer performance and project progress.

Here are some more quantitative metrics that can be used in conjunction with LOC.

Alternative Quantitative Measures

1. Function Points (FP): A measure of the functionality provided by the software to the user, considering inputs, outputs, inquiries, logical files, and interfaces.
2. Cyclomatic Complexity: A metric that quantifies the number of linearly independent paths through a program’s source code, reflecting its complexity and maintainability.
3. Code Churn: The amount of code that has been added, deleted, or modified during a specific time frame, indicating the level of development activity. “Churning” code is also a trick used to game the LOC metric. You add a lot of code and delete it, and then add it again.
4. Code Coverage: The percentage of code executed during testing, which can be used to assess the thoroughness of the testing process and the quality of the codebase.
5. Defect Density: The number of defects or bugs per unit of code (e.g., per 1000 lines of code), which can be used to evaluate code quality and the effectiveness of the development and testing processes.
6. Maintainability Index: A metric that combines various code attributes, such as complexity, size, and structure, to estimate the ease of maintaining and updating the software.
7. Commit Frequency: The number of code commits made to a version control system within a specific time frame, indicating development activity and collaboration.
8. Code Review Metrics: Measures such as review duration, review size, and review comments can provide insights into code quality and the effectiveness of the code review process.
9. Test Case Coverage: The number of test cases executed against the software, indicating the thoroughness of testing and the quality of the codebase.
10. “Code Smell”: The presence of code smells (clearly bad programming constructions), such as long methods, large classes, or duplicated code, which can negatively impact code quality and maintainability.

So, what should I use?

I don’t want to tell you what to do. Instead, let me tell you what I do.

Sadly, all the metrics presented above will, at best, give you a very partial and incomplete picture. At worse, they might be misleading, and even destructive.

Personally, I don’t use LOC to measure programming productivity. Nor do I use the alternatives to measure Programming Productivity (though I do use some of these as rough measures for Code Quality).

So, what do I do?

Two things.

1. In the end, a programmer’s goal is not to write code. It is to build something of value. One should evaluate and reward programmers based on this end value. This approach creates the right incentives, and motivates programmers to build meaningful things, as opposed to writing a lot of code.
2. This might be more controversial. Through experience, programmers acquire an intuition as to what good code is and what a good programmer looks like. And so, at some level, “you just know”. Project Managers and other non-programmers hate this, for obvious reasons.

What do you think? Do you agree? I would love to hear your comments.

DALL.E

PS: I was inspired to write this article, after I saw the response to this “tongue-in-cheek” post I made on LinkedIn. Hope it is clear - that the post was meant to be a sarcastic joke.

Nuwan Senaratna on LinkedIn: #github #topcontributor #srilanka #codelife #passionfortech…