LOC is an important metric to measure developer productivity

Thomas Hansen - Jul 19 '22 - - Dev Community

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 ... ;)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .