Hacker News Reader

Comment by cwp | Hacker News Reader

He's on to something here, but I think the asset/liability duality isn't a matter of your point of view. Code really is a liability, even from the high-level view in the boardroom. The asset is functionality. If you can get more functionality with less code, you improve your balance sheet.

By analogy, data is also a liability. The asset is insight.

View on HN

This strikes me as some sort of Orwellian contortion. It really is a matter of your point of view. Insofar as code is correlated with functionality (and it is at least to some degree), code can be viewed as an asset. In addition, code can be sold for cash, and this makes it an asset from the strictly financial point of view. It may have maintenance costs associated with it -- and these certainly need to be taken into account -- but that is not the same as being a liability.

Unless you've heard of places paying per line of code you seem to have missed the point of code being a liability. It's what it does that's valuable, not the volume of it

Code can only act through its volume. The fantasy of codeless functionality that is being propagated here is exactly that.

Functionality only exists because of code. The two cannot be fully separated from each other in the way that some in this thread are implying.

An airliner certainly is an asset (at least in the hand of a well run airline), but the lighter the frame the better: a lighter frame needs less fuel to fly, hence more money remains in the bank at the end. But without frame there's no plane, so you need some of it, just as little as feasible.

It's the same for code: a running program can certainly be a huge asset, but the less code you have the lower the maintenance cost. The concept is just harder to grasp than paying a kerosene bill each time a plane takes off...

I totally agree with your sentiment but I do want to add that adding code can be useful and make it better even if you're not adding functionality. For example, while it may be "cool" to turn a straightforward loop into a complicated one-liner (which would be "removing code while retaining functionality") that wouldn't necessarily be a good thing. The longer, more straightforward code is likely to have a lower maintenance cost.

I think the issue is that you are conflating lines of code with complexity. I certainly think it is better to write short programs, but it is wrong to think that less LOC == better code.

The most valuable kind of software IMO is the kind you don't think about because it never fails, and at that point your LOC measurements are irrelevant.

I did not mean to imply that the volume of code was directly tied to its value. I understand that value stems from functionality and not from quantity of code. But functionality does stem from code, as jsprogrammer said. If your code does X, and X is valuable, then the code is valuable -- I don't see what's wrong with this line of reasoning.

that's no more true of code than of land or anything else; thats just the fundamental idea of what value of a thing is, what you can use it to do or get.

So it's odd to say that value doesn't lie in code but in the functionality that code provides, without also saying that of everything else, and, to say it at all -- of code or more generally -- is just to use language in an atypical way (and,if its just of code, an inconsistent way as well.)

But the point is that you pay for the code in order to gain the functionality. Code is an expense. The application is the asset. If you want to add a feature to the application then you have to pay for it in developer time. The larger and more complicated the supporting code, the more time you will have to pay for.

I pay for X because X provides valuable functionality is generally true of productive assets. And it's not unusual for productive assets to depreciate or have maintenance expenses that must be born to maintain their functionality -- usually both.

So, while those are all valid observations about code, they don't make it a liability, they make it a fairly bog-standard productive asset.

So given the choice between having feature X written in 1,000 lines or 1,000,000 lines of code, you don't care which is which? I find that hard to believe.

If code truly was an asset, it wouldn't really matter if it was 1000 lines or a 1,000,000 lines as they're functionally equivalent right? Or perhaps the million line program would be worth more, wouldn't it? Code is an asset.

But the amount of code directly influences the maintenance cost, doesn't it? And maintenance cost is a liability, no? It's something that you're obligated to pay if you want to keep the asset productive. And an obligation to pay is a debt, isn't it?

Yes this is all stretching a bit, but it's not entirely wrong either.

To those practicing double entry accounting, this is entirely wrong.

You have asserted your statement to be true. OK. Why?

Here's my point. I can buy two factories to make cars. One costs $100mm and $100k/mo in maintenance to run (fixing machines, etc). The other costs $100mm and $10mm/mo to run. They make identical output, the exact same cars at the exact same rate with the exact same inputs and costs. Which factory should I buy? And why?

> Here's my point. I can buy two factories to make cars. One costs $100mm and $100k/mo in maintenance to run (fixing machines, etc). The other costs $100mm and $10mm/mo to run. They make identical output, the exact same cars at the exact same rate with the exact same inputs and costs. Which factory should I buy? And why

Actually, that analogy reveals the silliness of the assertion that code is not an asset. Because its equivalent to asserting that factories -- the canonical example of a capital asset -- are not assets.

That are code base with greater maintenance requirements with equivalent functionality to one with lesser maintenance requirements may be analogous to a higher-maintenance factory with similar functionality to lower-maintenance one (which isn't really controversial) doesn't support the idea that code is not an asset, just that maintenance costs is an important consideration in the net value of a productive asset, which, again, is common across all classes of assets.

That LOC might be a metric associated with maintenance costs of code doesn't stop code from being an asset doesn't stop code from being an asset any more than the fact that part county might be a metric associated with maintenance costs of industrial machines stops such machines from being assets.

Are we arguing over the true definition of the terms asset and liability or over the point the OP was trying to make when using these terms as a metaphor?

Hard to tell. The whole thing gets pretty wacky pretty fast. I think that metaphysically features are assets and code is a liability. Similarly production capacity is an asset and the machine that comprise that production capacity are liabilities.

So what does that mean? You end up with a (probably) tangible thing that has assets and liabilities all intertwined in it. Mechanically these tend to be inseparable. But when it comes to code, it's often possible to drastically reduce complexity (liabilities) while maintaining the features (production capacity) and so trying to value it exactly the same as a factory doesn't make a ton of sense.

For example in 2000 you might have spent $2mm making a big CRUD app that runs your business. And you might still value it at $2mm even though today a programmer or two, a year, and a modern web framework might remake it for $300k. And it might go from 100kLOC of "in house" code down to 20kLOC because the framework does most of the heavy lifting.

You don't often see that kind of thing happen in the physical world which is why people bundle everything up, but when talking about code it's easier to see how to split apart the value production from the value consumption to where a person might talk about code as a liability and the things that are automated as the asset.

No, the person's salary who made the code is the expense. The code is intellectual property that can be considered an asset, although without a pricing mechanism from a marketplace, it can be difficult to say exactly how much it is worth.

Unless you are willing to pay me to rm -rf your source tree, you are contorting the definition of liability.

If you can remove lines of code and retain functionality, then yes, I will pay you to remove code.

Conversely, adding lines of code but NOT adding functionality isn't worth a cent.

Arguably, programming class teachers charge students indirectly for adding lines of code without adding valuable[1] functionality.

The market value for code without valuable functionality is negative.

[1] Value as determined by how much anyone is willing to pay to use the software.

Tests and comments.

Comments are useful, if they provide insight. They are not useful, if they do not.

Tests can provide a number of things: they can serve as API examples, assure functionality, speed up implementing new functionality and debugging.

If you tests don't do these things, they are not worth keeping, either.

Depends if it adds anything else - readability, maintainability, flexibility, portability etc.

The "code as liability" argument seems, unless I'm mistaken, to be based on the idea that less code for the same level of functionality means less cruft, and therefore better support for the NFRs that I mentioned above.

That's often true, but not always.

If you're including those NFRs in what you mean by same functionality, then the number of lines of code is utterly irrelevant.

removing the tree without maintaining the functionality is damaging the asset

From an accounting perspective I am inclined to disagree. Firstly, the way you present functionality as asset and code as liability, you do not make it easy for me to read how they are components of a balance sheet. More specifically, how do you see your balance sheet improving while still being balanced?

Furthermore, both assets and liabilities (including capital) are stock measures. I would consider insight more of a flow than a stock. More specifically, I think it is the process and tools of achieving insights that is the asset. Whether data is part of this asset base is up for grabs, but accountants have not identified any reasonable way to measure it.

"...the light that falls on to your eye, sensory information, is meaningless, because it could mean literally anything. And what's true for sensory information is true for information generally. There is no inherent meaning in information. It's what we do with that information that matters." Beau Lotto

From a very interesting TED presentation.

http://www.ted.com/talks/beau_lotto_optical_illusions_show_h...

And I know I am confusing information with data, but no one has a convincing definition to separate between the two.

With respect to your comment about the difference between data and information - I think of information as data that has meaning.

This is a common distinction. The issue is that my information may be your data and therefore any such definition does not refer to data or information but to someone's relationship with it. I allude to that with the quote I included above.

excerpts from http://www.ribbonfarm.com/2014/02/07/an-information-age-glos...

Data: Any collection of information, bullshit and noise.

Information: Data that has been judged to be true or false through comparison with observed reality at a given point in time.

Bullshit: (1) Data (often a firehose) produced by someone who is indifferent to the truth or falsity of what is being said (2) Data that appears to contain more information than it actually does (3) Noise randomly tagged with truth-values to give it apparent legibility

Noise: The component of data that is neither information nor bullshit and at risk of being prematurely discarded ...

Falsehood: Information that is known to be inconsistent with the observed state of the world.

Truth: Information that is known to be consistent with observed reality at a given time and capable of being unpredictably turned into falsehood by a change in reality in the future.

Illegibility: Information or bullshit that looks like noise to those outside a system, due to the presence of a large amount of metis. (Derived from James Scott).

Metis: A collection of formulas that work to maintain the identity of a system.

Intelligence: The ability to separate bullshit from information.

Belief: Sincere acceptance of the truth or falsity of a piece of information.

Art: the process of creating information starting with bullshit.

I like the definitions, but I can't be the only who notices that according to these definitions data is "information and ...", while information is "data that ...". It looks like a circular definition, which definitely cannot help with distinction.

How about "data is the n-dimensionally measured point and information is data plus some reference and dimensional axes" as a working definition?

I don't know if I understand properly, but are the dimensions not implicitly at least defined if we have n-dimensionally measured point? Any additional dimension would be either irrelevant or would be necessitating additional data to populate the dimension

I think this is how Enron did their books.

I agree with your comment but I wanted to share:

I have constructed the argument before that if you consider functionality as an asset and code as a liability, you can consider a refactor as retained earnings (or stockholder's/owner's equity, whichever you prefer). Along those lines, refactoring code becomes much more palatable.

I know it's a flawed analogy because refactoring costs money, so it isn't really RE. It did help me answer a question along a similar vein to yours ("...how do you see your balance sheet improving while still being balanced?"); where I was assuming a reduction in liabilities satisfied "...balance sheet improving...".

As far as the balance sheet, less code means lower costs and more projects from development. Because it costs less to maintain less code than it does large, convoluted codebases. Are you better off with a codebase that has similar value (functionality) but much lower maintenance costs? The value of a codebase is the functionality it provides, not the number of lines of code in use.

Instinctively management will try to through more resources at a problem instead of paying off technical debt before it becomes unwieldy.

> Code really is a liability, even from the high-level view in the boardroom. The asset is functionality.

The programmers who understand and maintain the code are the real assets; everything else is a liability. Without those programmers, those programs will quickly rot because change is always happening and sticking a random programmer in there will over time degrade the program.

Smart companies know this, it's what talent acquisitions are all about. You want the goose that lays the golden egg, not the egg. The egg has some short term value, but it depreciates quickly, the goose is the real asset.

Exactly. Intellectual property is worthless. The only thing of value is intellect.

If intellectual property was worthless then Disney's workforce would consist entirely of live performers.

In an ideal world as specified by the 1900 US Congress, even Disney's intellectual property would depreciate over time, and the assets would be the animators who create new intellectual property.

...or their workforce would merely have a lot more animators, musicians, producers, etc and would necessarily produce more content more regularly than simply sitting on a mountain of IP and merely re-marketing it every few years with lots of lawsuits and lobbying mixed in to "protect" said mountain of IP.

They would also be able to re-use and remix the content of others (e.g. competitors) more regularly and the public at large would be able to do the same. Resulting in more content for everyone to enjoy.

Please see: double entry accounting.

Please see: context, we are obviously not talking about accounting nor using the words asset and liability in the accounting sense, nor was the article.

The programmers who understand and maintain the code are the real assets;

Not one in one hundred organizations believes this or operates as if they do.

I like the article conclusion a lot:

> Actionable insight is an asset. Data is a liability. And old data is a non-performing loan.

As comments react on the post's assertion that "code is a liability", I would translate this conclusion as:

Useful program is an asset. Code is a liability. And spaghetti code is technical debt.

I think the better analogy is inventory, which is an asset. The value of data depreciates over time. Having too much data that is not producing insight or value is inefficient asset allocation.

In other words, lean principles should be applied to data. Reduce data collection that doesn't add value. Calling data a liability is not quite the right analogy for me.

Also, both are stored in warehouses.

The problem with this is that while the value of data may depreciate over time the cost to store it also costs less over time due to Moore's law and Kryder's law.

The depreciation isn't the important part. The article suggests considering data as a liability in the accounting sense. But the author should have stopping at saying it's a liability in the non-accounting definition.

Assets have value, but there is risk associated with it. Assets like inventory can lose value because of depreciation, or because demand for the finished good has dried up, there's a risk of theft, there's a cost of storage, etc.

Data should be viewed as an asset like inventory and lean principles can be used to reduce your risk and produce customer value efficiently.

Reply on news.ycombinator.com