DEV Community

LOC is an important metric to measure developer productivity

Thomas Hansen on July 19, 2022

There's this superstitious belief in our industry that LOC count is irrelevant to measure developer productivity. In this article I will debunk tha...

Read full post

Ben Sinclair • Jul 19 '22

The idea of working in a team of 9 where every other developer was trying to get a free ride sounds incredible to me. People telling you not to do well because they don't want to look bad sounds the same - like something from a sitcom. If you experienced this, then you had shitty luck and you're good to be out of there.

In most cases, you're not reading stats about LOC, you're part of a team where people can see each others' work through pull requests and actual results - new features being merged in, that sort of thing - and the only time the numerical stats are important is in keeping the LOC added relatively low.

A new feature with a high sloc report compared to previous features is smelly, because it coule have reinvented the wheel somewhere or it's including useful bits that have previously been missed. An abnormally low number implies that maybe something's missing - like tests, perhaps - or that there's an opportunity to refactor existing features to use this improved technique.

I'd say that's where LOC is important - if it feels like the number isn't in the ballpark you'd expect, it's worth investigating. What comes of that investigation is completely subjective.

Thomas Hansen • Jul 19 '22

I'd say that's where LOC is important - if it feels like the number isn't in the ballpark you'd expect, it's worth investigating

I agree 100% here. It's always subjective and individual investigation needs to be applied ...

Keff • Jul 19 '22

I can agree with this one. Of course, as you said, there are other metrics we must take into account. Only using the LOC metric is not enough to make any decision.

I've had similar experiences to the ones you talked about where developers underdeliver (or at least it seams like it, from the LOC), and it can be hard for the team, demotivating and infuriating in some cases. But in some cases we were looking at the incorrect metric, and or missed a lot of context on why they delivered so little. In the end I think we should take LOC into account, but not only look at that, but also look at other metrics.

Thomas Hansen • Jul 19 '22

and it can be hard for the team, demotivating and infuriating in some cases

Free riders surfing on other peoples' work is the worst thing a company can experience. It demotivates everybody ... :/

JoelBonetR 🥇 • Jul 19 '22 • Edited

The point here is the exaggeration of the specific case.
23 LOC during 2 months is just ridiculous and only I can think of trying to find an explanation to this anomaly, my guess is a sum of:

High complexity/overengineered project.
The use of acronyms to name classes, entities and so which obfuscates the analysis and adds complexity to the development and maintenance.
Very long PR processes (PR->feedback->update->feedback... loop)
Bad usage of patterns and issues trying to re-use them in situations where they don't fit.
Tones of bureaucracy related to the project (bad Jira model, bad maintained confluence and so).
Not enough meetings with clients/whoever to unblock tasks.

Or it just canbe lazy devs 😂 which is the easiest explanation.

I think LOC is important, but there's a range of -25% to +25% regarding project average LOC metric plus taking into account the experience and knowledge level of the developer.
On the other hand, context is needed to evaluate each case, by rule of thumb an analyst dev will provide few lines of code than a dev that just develops.
And so on

Thomas Hansen • Jul 19 '22

On the other hand, context is needed to evaluate each case

One can never generalise, and there are no rules without exceptions, but I've heard too many times people tell me that "LOC is the least interesting measure stick in the world", when this is simply not true ...

JoelBonetR 🥇 • Jul 19 '22

Agree. On the other hand we can't state that more LOC = better in every case. Most of the time, applying KISS ends up on a more maintainable code :)

Thomas Hansen • Jul 19 '22

I agree, the less code the better as a general rule. However, when the product is code, and the code isn't there, you have a problem ...

JoelBonetR 🥇 • Jul 19 '22

Hahahaha that's it

Christopher John Pepper • Jul 21 '22

Lines of code is a terrible metric. Commits might not be.

There are plenty of days spent as a developer hunting down a strange bug only to fix it with a single character change (e.g adding "?" to a none null checked instance of a class).

The LOC does not reflect the effort and skill needed to track that down.

The commit will tell you all u need to know I guess.

But I would say u should know the productivity of your engineers by working with them, and looking at their pull requests. Anyone trying to measure engineers externally is going to get it wrong imho

Thomas Hansen • Jul 21 '22

Commits can also be gamed, by for instance indenting and de-indenting the same file multiple times. Everything can be gamed, and there are no single metric that works for all situations, but LOC is one metric that should be examined. However, I see your point, and I partially agree ...

Christopher John Pepper • Jul 21 '22

Also if developers know your using LOC as a metric then they are going to over comment, and pointlessly roll out code (e.g not use concise linq or use if statements instead of switch and ? null operators) or worse commit stuff only to revert it later.

Its like if you measure on bugs fixed, ur just gonna increase the number of bugs you get cause devs will leaver them in or create them to fix them later.

Thomas Hansen • Jul 21 '22

Like I said, everything is individual. Replacing manual analysis is impossible, and there are exceptions - However, I've heard the statement "LOC is irrelevant" way too many times, and it's often an excuse given by lazy developers to hide the fact that they're not working ...

Christopher John Pepper • Jul 21 '22 • Edited

Hmm perhaps, I would say you shouldn't use LOC as a metric, I would say if you are, something else in your process is missing.

Like I say commits are useful to review. But even those could be misleading from the outside.

A good example, if someone external had measured my team on LOC over the past 3 months they would say their productivity has gone down. They/we have built a small react game for a client, the first month was a flurry of new code building the engine for the game etc. But the last month has all been about refinement, small tweaks to the game logic to make it more fun, fixes to obscure bugs on certain mobile devices etc.

If someone had measured the team members on commits 5 months ago, they would have seen a series of small copy changes. Not due to lazyness but due to a very frustrating product backlog issue which I was spending a lot of time fixing in the background. You could say the commits could highlight an issue here but I'd worry the blame Would be put on the wrong people

Thomas Hansen • Jul 21 '22

You're right, but then the article wouldn't be as controversial, so I have to exaggerate some points. I don't disagree with you, I just feel that the statement "LOC is useless" is abused by (some) developers, such that they can hide ...

Alex Lohr • Jul 19 '22

That reminds me of a collage who applied at a company that wanted to know how many keystrokes per minute he did on average. He didn't want the job, because rewarding quantity over quality of code is a red flag.

That said, LoC is a valuable metric, but it's even more important to measure the quality (usually in 100% / WTFs per minute).

Thomas Hansen • Jul 19 '22

That reminds me of a collage who applied at a company that wanted to know how many keystrokes per minute he did on average

Every single ace developer I know would have aced that test, including me. Measuring keystrokes is actually a better idea than asking the candidate to find the pivot value for some QuickSort set ... :D

However, I see your point ...

Doug Schwartz • Jul 19 '22

At one of my recent gigs all of us took turns being the person on call for the week. As part of our daily tasks we approved PRs. It soon became obvious who was productive and who was not. More than one of us mentioned to our manager that contributor X was not doing a d@mned thing. We finally kicked them out of the group. Keeping a bad apple is toxic for the rest.

Thomas Hansen • Jul 19 '22

In a small group it's difficult to hide. In larger companies it's easier. When management itself is hiding, the whole tree is rotten ...

I kind of experienced the latter ... :/

Olivier • Jul 19 '22

In my team we measure productivity with thoses questions in mind :

Does the deadlines are respected ?
Is the customer satisfied ?
Is the code quality is good enough ?
Is there a lot of bugs after a release ?
Is the onboarding of new developers easy ?

The number of lines is irrelevant for us, and yet our 2 largest projects exceed one million lines each.

During the 2 month where you 8 developers change 23 lines what did they do ? If the answer is nothing there is a management problem , it shouldn't take more than a day or two to figure that your dev are fooling around. But maybe they where just working on peripherals tasks (documentation , deployment, debugging , architecture , etc ...)

Thomas Hansen • Jul 19 '22

During the 2 month where you 8 developers change 23 lines what did they do ? If the answer is nothing there is a management problem , it shouldn't take more than a day or two to figure that your dev are fooling around

Probably netflixing around from their hammocks is my guess ... :/

peerreynders • Jul 20 '22

ref: "There was a particular manager who wanted to understand each individual team member's contribution in terms of story points.

OK, so we're gonna measure everyone's story points, am I going to cull the weakest people in the team and so there's a chap (I don't know if any of you guys have come across him, his name's Tim McKinnon, phenomenal developer and wonderful wonderful coach and all-around lovely human being) so he's in the team and he's coaching in his team and his velocity was zero.

Tim's velocity, Tim's personal velocity was zero points and so the project manager said, it's obvious isn't it, that's the person we cull and I said no, no, no, no you don't get to do that.

The reason Tim's velocity is zero is, Tim never signs up for stories because Tim knows he is much more effective pairing with everybody in the team. He is the minister without portfolio within that team.

So what he does, he accelerates the whole team, he is that 10x developer by not committing anything himself. He enables the whole team to go fast.

I said, if you take that guy out of the team everyone on the team will slow down. You will cripple that team."

Thomas Hansen • Jul 20 '22

Luv it! As I said, it's always individually! You can never generalise ...

John Morales • Sep 7 '23

We leverage service providers to provide contract developers. To determine the ROI of these providers we use a combination of commits, code changes, trending of code changes, who are contributing to code, pull requests. We are paying for these developers to delivered value and the amount of work being produced. We need to ensure we are achieving maximun value from these service providers. We are interested in correlating the coding effort to the existing metrics we have collected, anyone have any suggestions. Another factor is the developers experience, entry level developers versus a principal developer. We should expect a more experience developer to accelerate development efforts. Lastly, Generative AI for Code Assist will improve coding efforts as the solution continues to mature overtime. Love to hear your thoughts.

Thomas Hansen • Sep 7 '23

It sounds like you know what you're doing. Does it work?

Luca Cervone • Jul 29 '22

Well, this collection of articles is amazing. Nothing else to say. There is nothing to comment because I share EVERY SINGLE STATEMENT you wrote in this articles. But for the following one, there is something to say:

At this point I guarantee you that some software developer is going to pop out of the woodwork and tell you he created a bot to apply a single change in his codebase, for then to automatically commit it towards git

What I would do if this happens, is to ask her to show me the code of her bot. If the code is good, then it means that she is a good developer. And she is also a good worker, and perhaps a kind of genius, because she created quickly something that solves her problems. Then I would hack my job evaluation process to make her modify the bot's code, so that she would be able to cheat again with the new rules. And I would iterate again. Until when? Until I've got what I needed and she didn't know. I've got that plugin that automatically commits on github when certain code's requirements are matched ;)

Moral of the story. I think that there are developers that can write code and enjoy to write code in any situations. And then there are developers that have the real "forma mentis" to be a developer, and so they enjoy to write code only if they think they are doing something useful (contextually or generically speaking). When you face one of the latter, the first thing you should think is: "why she is not enjoying in doing that?" ... it would be incredibly enlightening to understand that the problem is you. You have probably over engineered what you are doing and that functionality or whatever is useless ;)

ah ... of course ... there is a third class of developers. The ones that simply do not want to work but they want to be paid. But if they enter a company, the error was by the human resources team, and not by the technical teams ...

Anyway, thanks again for these articles!

Thomas Hansen • Jul 29 '22

this collection of articles is amazing

Thank you ^_^ (blush!)

What I would do if this happens, is to ask her to show me the code of her bot. If the code is good, then it means that she is a good developer. And she is also a good worker, and perhaps a kind of genius, because she created quickly something that solves her problems

Hahahaha :D

I agree, 100% percent!! :D

Thank you again, this comment made my day ^_^

Luca Cervone • Jul 29 '22

You are very welcome!

Thomas Hansen • Jul 20 '22

Eliminating LOC by simplifying and creating better code is always a good thing the way I see it. Individual analysis always needs to be applied.

Josh • Jul 27 '22 • Edited

EDIT: After thinking about the problem a little longer, I realized there was an even faster and more memory efficient implementation of the method, so I added it to the end of the list.

Which of these deduplicate methods is "laziest"?

def loop_deduplicate(array)
  new_array = []
  array.each do |item|
    if new_array.include?(item)
      # no-op
    else
      new_array.push(item)
    end
  end
  new_array
end

# hashes in Ruby retain insertion order as of version 1.9
def hash_deduplicate(array)
  array.reduce({}) do |hash, item|
    hash[item] = 1
    hash
  end.keys
end

# Ruby allows for one-line method definitions as of version 3.0
def union_deduplicate(array) = array | array

EDIT 2 (and hint!): As the O.G. edit should imply, this is very much a trick question!

Rainson12 • Jul 19 '22

How did you measure the LOC across all branches? Maybe changes just weren't committed?

Thomas Hansen • Jul 19 '22

All branches? What branches ...? :/

Rainson12 • Jul 19 '22

I mean.. People work on branches? Did you only count changes to your main/master?

Thomas Hansen • Jul 19 '22

[sarcasm_warning]
No sjiit ...? :D
They do ...? :D

Seriously ...? :D
[/sarcasm_warning]

23 LOC of changes, 8 developers working "full time", 2 months, all branches ...

modaye • Jul 27 '22

It's so lazy that developers can't change just 23 lines no matter what they do