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.

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.

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.

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.

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.

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.

removing the tree without maintaining the functionality is damaging the asset