Hacker News Reader

Comment by brlewis | Hacker News Reader

>Isn't it more useful to think of code not as an asset but as a liability?

No, it is not. For consistency, you'd have to start thinking of everything you own as a liability, and only use "asset" to refer to a problem solved by something you own. This would be confusing to everyone you talk with about assets and liabilities. On a day when you didn't drive anywhere, you'd point at your car and say "I got no assets from this liability today." (There would be some truth in that statement, but your listeners would definitely be confused.)

EDIT: I should add, I believe Dijkstra was using hyperbole to make a point with the "lines spent" part of https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...

View on HN

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

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.

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.

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.

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.

> you'd have to start thinking of everything you own as a liability

Everything I own is a liability -- and an asset at the same time.

True in a blurry kind of way. Perhaps the word “net” clears up a lot here.

Some things are net assets, some things net liabilities.

The distinction matters a lot.

Maybe helpful to split into 2 parts: code functionality = asset, code maintenance & debugging = liability. So you must balance the 2.

Writing less code minimizes the liability side. Combined with a "YAGNI" stance, you can minimize your codebase total liability while writing the least amount of code required to do the job.

Reply on news.ycombinator.com