Comment by karmakaze | Hacker News Reader

Comment by karmakaze | Hacker News Reader

Parent Full thread

> The practice is pervaded by the reassuring illusion that programs are just devices like any others, the only difference admitted being that their manufacture might require a new type of craftsmen, viz. programmers. From there it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

It doesn't sound like hyperbole to me. "lines of code" without context is a liability, more is not better. The correct side of the ledger is being stated as liability, if we're to consider lines of code at all.

Although more lines _might_ situationally be better if it means the difference between a very clever but confusing one-liner versus a more verbose but comprehensible handful of lines. So like many things in engineering... it depends.

If you were advising an airplane manufacturer where production was tracked by weight, you might admonish them that they were putting airplane parts on the wrong side of the ledger. But later, after they changed their practices to stop encouraging the production of useless parts, the remaining airplane parts would be counted as assets, not liabilities. You, and they, would look back on the ledger comment as hyperbole.

> the remaining airplane parts would be counted as assets

I'm not in the industry so can't say, but the weight of parts is always a liability as it contributes to fuel consumption. Parts also require maintenance (but not necessarily by weight).

An operational plane as a whole is certainly an asset. Perhaps this is how we should handle software, the whole is an asset, the quantity of parts that need maintenance are liabilities.

Most assets have costs associated with their ownership. So one might temporarily think about ownership in terms of liability as a reminder that those costs exist. However, you should then go back to using "asset" and "liability" in a way that people understand. Don't thank your collaborators for adding useful liabilities to your codebase.

While those airplane parts might be assets, they're still deprecating and have maintenance liabilities. Existing code might be an asset but it has costs to run and maintain.

well I consider it to be a metaphor for the maintenance required for the code. A piece of code 10 lines can be less of a maintenance problem as a oneliner if the latter achieves this via some needlessly esoteric technique.

> "lines of code" without context is a liability, more is not better.

Doesn't more lines == more features == more value.

How is that not better?

I don't think that equation holds.

More lines of code do not always mean more features.

More features do not always mean more value.

More lines does not equal more features! I just ripped out a bunch of unnecessary debug logging, the computation for that, unnecessary data copies, and then a 200 line method turned into 3 lines. What's more, the debug code had bugs I in it and would crash if it actually caught an exception.

To my knowledge researchers have not found a single metric that correlates with bug count other than total lines of code. Unit testing, developer experience, none of it is predictive of bug count, only size of code base has a correlation.

My first hundred lines in a module might be a feature but the next hundred lines in that module are likely handling unforeseen edge cases. My next -150 lines can be me refactoring the module to just be better designed.

Counting lines is a terrible metric for software. It lacks any sort of useful context.

if you adopt LoC as productivity metric then this is what you will get:

first 6 months: more LoC => more features next 6 months: more LoC => less features next 6 months: more LoC => 1 feature next 6 months: more LoC => some existing features not working well

and so on

because a new feature is not only adding code but changing code.

and the more code you have the more you have to change it.

Reply on news.ycombinator.com