Why your Lines of Code per day are not the right productivity metric—and what to use instead
Practice makes perfect. That’s what they say and it’s a valid truth for most things in life. In software development, like in any other profession, true experience is gained “in the field”, not from a book. And for software engineers, this field is writing code.
Their experience comes from practice, and when it comes to that, sheer volume really matters. This is an important insight for anyone looking to gain a foothold in the industry: writing lots of code has a tendency to make for experienced programmers.
However, this does not make code quantity something that can be used to incentivize programmers, or which outsiders can use to judge development work and developer productivity and performance. In most cases, a large volume of code does not necessarily mean quality, efficient code.
The ongoing search for software development metrics is a tale as old as time—one that team leaders are all too familiar with. One of the most controversial of these metrics is Lines of Code per day (LoC).
The use of LoC has been highly debated through the years. At Waydev, we see this particular metric as having the potential to be both useful and detrimental for software development teams. It all depends on how you use it.
As a singular metric to establish developer productivity and/or code quality, LoC can be deceiving. A team leader or software development manager needs to evaluate the impact of the code being produced by their team. Using lines of code as a code quality metric by itself is not an efficient way to evaluate developer performance, since it also counts commented code or rewrites. It also tends to encourage some bad behavior, at a team level.
However, LoC can still be a useful metric in software development and its continued use throughout the years is proof of that. In this article, we want to talk about the advantages and disadvantages of this metric and why software engineers should still track it.
Read on to find out when and how to use LoC properly, what the right way to measure productivity in software development teams (as a manager) is, and how to make sure you only evaluate efficient work and not junk code and rewrites.
LoC is probably the single most talked about developer metric. Used since the early days of COBOL, the relevance of this metric is still talked about today, though, mostly with a disparaging tone. How did this age-old metric gain such a bad reputation?
Large software projects are almost always talked about based on the number of lines of code they contain. It’s become a habit for people to talk about the size of their codebase when bragging about their accomplishments.
However, even early on, programmers argued about the “value” of a line of code. The argument against LoC was that it was simply a measure of how much you typed, and not how much quality code you wrote. Strictly using this as a metric would lead to people inflating their LoC by not refactoring their code properly and creating future maintenance problems.
LoC has had a long journey throughout software development history and its advantages—when used in the right context—are beginning to be better understood. Measuring the Lines of Code per day metric can give you a high level view of the size of a software system, how the codebase is changing and potentially the complexity of that code base.
With that said, the metric can yield incorrect behaviors, expectations, and results, when used in the wrong context.
At face value, LoC may seem like a metric that makes sense. If you use it right, you can encourage code creation and support greater transparency, collaboration, and continuous delivery.
A bad example is to use it as a measurement of productivity. If you measure developer productivity by Lines of Code per day, then your developers will tend to use more lines to deliver less. And that’s just one example of the negative behavior and effects using this metric incorrectly can have.
The problem with using Lines of Code per day as a productivity metric is it measures the complexity of the solution, not the complexity of the problem. And like most metrics, it means very little without context.
LoC has become irrelevant for productivity. Just look at the infamous “-2000 Lines Of Code” story that involved Bill Atkinson’s work on the Original Macintosh computer. It’s a fascinating tale of why it’s hard to measure progress just by using lines of code, without taking into account the developer’s experience or proper context.
“Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.”- Bill Gates
As leaders in engineering, team managers are constantly asked to produce numbers to show how their software development team is improving.
Are we getting better? Where can we improve? As a manager, it can be incredibly difficult to not have the answers to these questions—even more so when you have to answer to outside stakeholders.
The desire for key performance indicators can lead you to measuring the wrong things or using metrics in the wrong ways, even when you see the flaws. In particular, it can be easy to fall into the temptation of using LoC as a valid marker for way more than it was intended.
Using LoC as a productivity metric can lead to an increase in code complexity, which can expose you to dangers such as a risk of increased:
As a team leader, your goal is to encourage collaboration, create efficient workflows, and optimize development processes while having a tangible way to express that to other stakeholders. So why would you measure productivity through a metric that incentivizes the opposite of the good practices and behaviors you want?
It’s easy to see why this metric is usually looked down on and even used as a joke by developers and managers alike. However, there are a few ways to look at total LoC to learn valuable things about your team and your developers.
A good example of use of total Lines of Code is in the metric: bugs or defects per line of code. It can give you a gut feel of how many bugs you should expect to find in your project. Remember: more code does not mean quality, functional code.
Another way of looking at LoC count is only analyzing it AFTER other appropriate code quality metrics have been applied. Basically, during the development process, you should worry about quality, performance, usability, and conformance to specifications. Get those right, and the project will probably be a success.
When the dust settles, look at LoC count. You might be surprised to see how much you got out of just 5,000 lines of code. Like all metrics, it needs to be evaluated with care. A single metric usually is not sufficient for a complete answer.
Instead of tracking Lines of Code per day as a productivity metric, what you’re actually looking for is a combination of metrics that allow you to measure the complexity of the work being done by the development team and to see the severity of changes when legacy code is modified. Here’s how to do it.
The LoC metric can be useful in the measurement of productivity, but only if it’s used in correlation with other code quality metrics to establish impact. Here’s a selection of relevant code quality and developer productivity metrics you can track:
Of these four metrics, measuring Impact and Activity can truly make a difference in how you track team productivity. The two work together to provide a clearer image of the cognitive load each engineer carries when implementing changes to your codebase.
At Waydev, we understand the temptation of the LoC metric and can see the advantage of tracking it in the right context. At the same time, we are thoroughly aware that, when used on its own, the Lines of Code per day metric can be deceiving. That’s because it takes into account aspects that aren’t truly productive (such as rewritten code or comments).
To overcome this, one of our Waydev metrics is Impact, a measurement of the depth of the code changes that are happening, that goes beyond simplistic measurements like LoC.
This set of software production metrics takes into account:
These data points are continuously improved upon, on a monthly basis to provide a metric that translates engineers’ output into business value and cognitive load.
Team leaders that head large engineering teams can find it difficult to keep track of who is succeeding and who is struggling, or how the team as a whole is doing.
What we propose is a way of setting a standard around checking in code every day—a simple yet powerful measure to help ensure the ball moves forward every day. That’s where the Active Days metric can help.
In Waydev, an active day is any day where an engineer contributes code to the project. You can use it to identify factors that are causing a drop off in your team’s ability to check in code. Then, course-correct by bringing the team’s focus back to what they do best: writing great software.
By using Waydev to track these metrics in context, you’ll be able to ask better questions and advocate for the team with relevant data:
Waydev lets you increase visibility about team contributions, see where the most significant impact is being made, identify areas to give concrete feedback, and help teams understand how process changes impact the team’s effectiveness.
Being a manager and not being able to measure your team’s performance properly can be frustrating. Waydev can help you measure the amplitude of code changes that are happening in a more complex manner than measuring raw lines of code.
Schedule a product demo if you want to talk to an expert in software development metrics.
Ready to improve your teams' performance?
