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

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.

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.

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.

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.

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.

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

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.

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

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.

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

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.

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

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

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.

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.

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.

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

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

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.

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.