There's this superstitious belief in our industry that LOC count is irrelevant to measure developer productivity. In this article I will debunk that belief, and show how it's one important metric to measure performance. LOC is not the only metric, and there are exceptions where it's completely irrelevant, but it's still much more important than what most developers claims, and waving it being irrelevant is often a crutch for lazy software developers to hide behind, such that nobody shall notice they're not doing their jobs.
I once worked for a company as an architect. I had 8 developers on my team whom I was supposed to manage. I once went through all repositories to measure how my team performed, and for a period of 2 months there was 23 lines of code changed in our entire codebase. 23 lines of changes in two months for 8 developers. The industry average is between 325 and 750 LOC per month per developer. This implies that my team as a whole had delivered roughly 0.6% of the industry average. I tried contacting my superiors about it, without conveying names or blaming my team members in any way. I was told to "stop delivering. I wasn't expected to deliver". I resigned a week later ...
LOC is not the only important metric, and there are developers whom are doing a great job even though they rarely if ever commit code to your git repositories. An example from Aista is Mohsen who is waking up at 7AM in the morning, and working non-stop until at least 6PM, and always available if needed. However, his job isn't to commit code, but rather to maintain our Kubernetes cluster, and he is doing an amazing job at it too. Other examples might include testing engineers whom might be doing an amazing job even though they rarely if ever commit code to git repositories. There are also other exceptions to the rule, where software developers who never committed a single line of code might still be extremely valuable for your organisation, such as illustrated above with Mohsen. However, if your job is to create software by coding, and you deliver 2.6 lines of code per month, somebody needs to talk to you about your performance.
Hence, realise that when (most) software developers claims that LOC is completely irrelevant, what they're really saying is the following.
I'm lazy, I don't like to work, but I love getting paid
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 - I should know, because it was the only way somebody was able to outperform me at GitHub for the country of Cyprus. Counting LOC alone is meaningless for these reasons, but having a human being read through commits and verify that people are actually delivering, by checking changes to the codebase, ensuring things are actually done, is crucial for an organisation who is focusing on delivering. And if somebody in your organisation now objects towards that statement, you should reconsider your hiring strategy ...
Free riders or "surfers" not doing their jobs, destroys the moral of everybody else in your organisation, since everybody can clearly see with their own eyes who is delivering and doing their jobs, and who is not. Hence, LOC is one important metric to measure developer productivity. It's not the only metric, and there are exceptions where it's not relevant, but it is relevant as a general rule of thumb ...
And today, it's dead simple to measure LOC thanks to Linus Torvalds and git ... ;)
Top comments (35)
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
slocreport 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.
I agree 100% here. It's always subjective and individual investigation needs to be applied ...
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.
Free riders surfing on other peoples' work is the worst thing a company can experience. It demotivates everybody ... :/
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:
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
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 ...
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 :)
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 ...
Hahahaha that's it
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
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 ...
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.
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 ...
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
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 ...
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).
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 ...
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.
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 ... :/
In my team we measure productivity with thoses questions in mind :
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 ...)
Probably netflixing around from their hammocks is my guess ... :/
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."
Luv it! As I said, it's always individually! You can never generalise ...
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.
It sounds like you know what you're doing. Does it work?
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:
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!
Thank you ^_^ (blush!)
Hahahaha :D
I agree, 100% percent!! :D
Thank you again, this comment made my day ^_^
:D
You are very welcome!