For me LoC is a good initial metric. I don't know why everyone refuses it outright. Yes, there're cases where someone will spend month just to delete 1 line and that would be productive. Or when someone will autogenerate 10k LoC spending 5 minutes. But keeping it in mind I still use LoC as initial metric when I need to estimate PR complexity or project complexity. I guess it should not be the only metric and it definitely should not be the metric which is used to estimate someone's productivity, at it's very easily gamed.
It's good because I need few shell commands to measure it.
It's useful for telling how much effort went into a software system, and how much it will cost to maintain it, but it's not useful for telling how much effort went into a task, even when it's not being gamed.
It also doesn't tell you how much effort should have gone into a software system. Spend six months writing your own message queue? 16384 lines of code. Spend two weeks wiring up your system to RabbitMQ? 1024 lines of code.
Right. I can see it as a relative metric. A 20k LOC project is probably less complicated (complexity, features, screens, whatever) than a 200k LOC project.
Not always. LibreSSL is probably smaller than some applications but much denser with complicated code than a simple system with lots of CRUD screens.
But it’s an easy to grasp metric. It’s also quite easy to figure out. It’s automated and doesn’t require weeks of study by specialists.
But as we all know, using it to manage productivity of individuals or teams can be heavily misleading.
imo those times where you spend a lot of time to fix something with one line of code are actually an indication that the code is pretty bad. It shows that it was hard to understand, that there was massive complexity in the system and that one line was probably additive and added a workaround or extra configuration of some kind. I've never spent a massive amount of time for ~1 line of code and been happy about the effort. If someone had only architected this thing better or explained it or documented it then it would have been trivial to add that line.
Sometimes things have subtle bugs that it takes a long time to track down. This happens less often when they're well written, but it still does happen. And when it happens, the bug fix is often just one line. It's a frustrating experience, but sometimes still worthwhile.
Also, though, I don't think that needing only 1024 lines of code to wire your system into RabbitMQ is any kind of indictment of the quality of RabbitMQ or of the code being wired into it. It would be even less of an indictment if it was only 128 lines or 16 lines or 1 line. But sometimes you need to grok a whole new paradigm; if you've never worked with AMQP before, you probably aren't going to be able to write those 16 lines in half an hour.
Similar comments apply to other domains with well-developed libraries for them. OpenCV, BLAS, regular expressions, LALR parsers, SQL databases, GNU MathProg, and so on: if you haven't worked with them before, it's probably going to take you a while to learn enough about them to apply them to your problem, and then you're going to produce an extremely small amount of code to actually use them. But that doesn't mean your time learning about them was wasted; quite the contrary.
It's usually a sort of shibboleth (or the opposite of one?) - somebody asking about LoC, especially a new manager, sends up alarm bells of "this person doesn't understand coding."
Because it's so obviously easily gamed. There are some very specific contexts in which LoC is actually useful. A codebase with 1M LoC is vastly different to deal with than one with 100,000, no matter the language.
Goodhart’s Law: when a measure becomes a target, it cease to be a good measure.
It's good because I need few shell commands to measure it.