Lines of code — how to not measure code quality and developer efficiency

Lately I have a person who pings me daily asking how many lines of code I have written today. The first time was on the weekend. My answer was “none, as weekends I concentrate on not doing computer things with my partner” which is an excellent idea.

However, lines of code are often seen as productivity or even quality of a developer. And that’s nonsense.

When Elon Musk took over Twitter he asked people to print out (!) the code they’ve done in the last few days to prove their worth. This lead to a lot of ridicule, and well deserved. This isn’t the 60ies.

When pressure rises in companies you often have to prove your worth as a developer. You also have to prove your department’s worth as a lead developer. And as lines of code are easy to measure, this is often the hammer used to hit the nail in the coffin of company trust.

The amount of lines of code is a weird thing to measure as there are several things that interfere with it:

• If you look for a lot of code and equal that as efficiency, the code might actually be bloated nonsense to hit a goal of “x lines of code”
• If you look for a small amount of code, it might be overly terse or use a lot of dependencies. I can write 5 lines of code that do the job, but under the hood include 3 libraries of 2MB each
• We live in a time of preprocessors, bundlers, compilers and conversion for almost every code we write. So the original count of lines is pretty pointless. How much code gets shipped to the end user, is, of course, another story.

The amount of code necessary depends on a few things that can’t be measured in lines. Much like you can’t value the quality of an essay or book by the amount of words.

Code should first and foremost do the job it is written for. The outcome should be a product for the intended audience. For end users this means an app they use without any security and privacy issues that’s easy to use. For other developers, it’s similar. The code should play nice with other code, not have any performance or security issues and be easy to include. Often this means concentrating on the documentation, rather than the code itself.

So why do people care about the amount of code written? Well, it could be concerns about your developers not being seen as doing enough. It could also be a worry that your product has become bloated and hard to maintain. But often I think it goes back to finding one way to measure things. One way we learned in school. When students are asked to write an essay, the demand comes with a challenge of “at least x words”. That’s why. This has entered meme territory years ago.

An equivalent in code would be: “write a function that checks if a number is between 1 and 10”.

A pretty decent solution is:

function isOneToTen(number) { 
  return number > 0 && number < 10 
}

If LOC is your end goal, just do:

function isOneToTen(number) { 
    if (number === 1) {
        return true;
    }
    if (number === 2) {
        return true;
    }
    if (number === 3) {
        return true;
    }
    if (number === 4) {
        return true;
    }
    if (number === 5) {
        return true;
    }
    if (number === 6) {
        return true;
    }
    if (number === 7) {
        return true;
    }
    if (number === 8) {
        return true;
    }
    if (number === 9) {
        return true;
    }
    return false;
}

Both work, and you could argue that the longer one allows you to add more use cases. You could, for example, react differently to different numbers. However, we all can agree that this is not efficient code when it comes to writing and reading it as a human.

Interestingly enough, code like this can often perform really well. I remember working in very limited environments, like 8 bit computers. And there writing more often meant better performance as the code didn’t need expensive computation. These days are over though, and often micro-optimisations like these cost more time than they are worth.

What about keeping things as short as possible? Often you have competitions that measure the cleverness of code and skill of the coder by the terseness of their code. The first money I made with code was winning a competition in the “64er” computer magazine for a 20 line of code BASIC program that was a text editor in 1990. You also see one-liner contests and the like. Is smaller code always a sign of quality? I’ll write about this next time.

For now, please stop seeing lines of code as proof of worth for engineers. It just shows that you have no idea how building products with software works. Often the best code is the one that didn’t need to be written. Writing code is one task and doesn’t need to be the start. A much better investment is thinking about the product and what you want to achieve in the amount of time you have. Code can adapt, so can developers. Think about the needs of your users and validate features before creating them. The amount of code is only important when it becomes a performance or maintainability issue.