Hacker News Reader

Comment by khazhou | Hacker News Reader

Some people, perhaps you as well, take offense at LOC metrics because they're (in theory) easy to game, via redundant code, whitespace, verbose vs concise languages, etc. And because good developers know that small code and systems mean fewer opportunities for lurking bugs and points of failure.

BUT, if a team of developers is not padding their code, nor has shitty programmers who write page after page of nonsense, then in the end the proportion of functionality to LOC should be fairly stable, and thus LOC is a useful and meaningful proxy metric for the amount of new or changed functionality in a codebase.

View on HN

I'm not offended I just think its shit.

Its not difficult to track "velocity" via story points,features or bugs and is at least a step in the right direction.

LOC going down is often adding the most value.

Sure, deleting unused or bad code is a good thing, or refactoring or rewriting something more tightly. But you can't implement a new feature just by deleting code. I've never been in a codebase that did more and more by getting smaller.

People also take offense because a management weenie can misread the metric and penalize people who delete code, or write concise code, or solved a super tricky critical bug after a month of debugging with a one-line change.

But I still claim, these all normalize in the end. If a developer on my team has committed only 30 lines in three months, sorry but I'm gonna be skeptical of their actual productivity.

> But you can't implement a new feature just by deleting code.

No, but you can implement a "story", i.e. the removal of code is presumably a ticket somewhere in the system. (Or could become one.)

> I've never been in a codebase that did more and more by getting smaller.

Run on a smaller system? Run faster?

(I'm not sure whether or not I agree with the parent's point, nor yours, just offering suggestions.)

> If a developer on my team has committed only 30 lines in three months, sorry but I'm gonna be skeptical of their actual productivity

If LOC is what you rely on, I'd be sceptical of many things, sorry not sorry.

> If a developer on my team has committed only 30 lines in three months, sorry but I'm gonna be skeptical of their actual productivity.

I've just committed 3 lines that fix a bad intermittent race condition that took over a month to track down (partially because I can't test it and have to rely on other people who aren't 100% available). Is that unproductive?

It's not.

On the other end, I'd fully expect someone doing that producing : - 3 lines of fix - A comprehensive documentation of what happened here, how to diagnose it and track it down, and how to avoid it in the future, (ideally if the company supports it with an oral explanation to concerned teammates).

In the end, I'd be very skeptical of one month of work letting 3 LOC as the only tangible output too.

> A comprehensive documentation of what happened here, how to diagnose it and track it down, and how to avoid it in the future

The problem and diagnostic conversations are documented in the JIRA ticket; the solution is documented in another ticket which "fixes" the first one (for abstruse internal reasons); and more commentary is provided in both the comments around my fix and my verbose commit message.

(Also there's a whole bunch of angry Slack ranting about this issue but that probably doesn't count as "documentation".)

I never meant to say you did a bad job (looks like you certainly did a great one !), but just that a month of work typically leaves in the end, for good reasons, more than 3 LOC in "committed" (in the sense of accessible to the company as an asset in the long term) work, which was apparently the case for you too !

> leaves in the end, for good reasons, more than 3 LOC in "committed" work

I suppose it depends what people mean by LOC. I guess my 3 LOC isn't actually just those 3 LOC. Definitely an interesting thing to think about at least. Ta!

During the time those others arent available as you say I would expect you to be going through the backlog and looking for other ways to contribute.

That assumes there's sufficiently small chunks of work in the sprint (we're not allowed to touch anything out-of-sprint) to fit into the gaps whilst I'm waiting.

You may want to push back on that. I understand the reasoning but anytime upper management tells people not to work on stuff there is usually a communication breakdown some where.

Story points vary wildly between teams. I'd argue that they're a worse metric than LOC

Reply on news.ycombinator.com