The code to produce those runnable programs is a liability.
It's a necessary liability for a sustainable software business, as without the code fixing bugs is nigh-impossible (though not theoretically impossible - long-ago programmers wrote and read raw machine code).
But, the code itself is not what produces value. That's the code's output.
(Yes, you could be clever and say "but what about interpreted languages?"
I'd respond by pointing out that it's pretty rare to distribute a pile of executable code files to end users. Front-end JS only producing UX if delivered as part of a website, and similar principles hold for other interpreted languages - they're effectively object files once deployed, as in any deployment they're being run by the interpreter, not read by a human.)
> The code to produce those runnable programs is a liability.
That is total nonsense. So you throw away all your code after you built the program binary to avoid the liability? Don't think so, that code is a massive asset and throwing it away would make continuing the project unfeasible most of the time.
> It's a necessary liability for a sustainable software business, as without the code fixing bugs is nigh-impossible
Ok, so you agree with me, the code is a massive asset since it is the code that lets you change the program. Code is there to help programmers do their work, that is valuable as you say.
> But, the code itself is not what produces value. That's the code's output.
Both produces value. The code is valuable since it makes it easier to inspect and change the program. That is value. It isn't uncommon to sell source code access for products, why would anyone pay for that if seeing the source code is a liability? No, of course it is an asset, people arguing otherwise have just gotten too hooked on the "code is bad" mantra and try to argue all code is bad even though code obviously is very valuable.
Edit: And to be even more clear, throwing away the code and trying to work directly with a program binary creates technical debt, that is way worse debt than keeping the source code around. Code isn't inherently technical debt.
Code produces value for programmers, but none for end users. Software businesses can thus usually only charge end users for access to the runnable programs (or running programs, in an SaaS business's case).
You're certainly right that when a business's customers include programmers who want to extend or modify the programs, the source code can be an asset. I was mistaken to say categorically that code's never an asset.
On average, though, I think it's still more often a liability on the balance sheet.
It's why we lionize programmers who cut out thousands of lines without removing any features - they reduced the liabilities while retaining all the assets.
No - runnable programs are an asset.
The code to produce those runnable programs is a liability.
It's a necessary liability for a sustainable software business, as without the code fixing bugs is nigh-impossible (though not theoretically impossible - long-ago programmers wrote and read raw machine code).
But, the code itself is not what produces value. That's the code's output.
(Yes, you could be clever and say "but what about interpreted languages?"
I'd respond by pointing out that it's pretty rare to distribute a pile of executable code files to end users. Front-end JS only producing UX if delivered as part of a website, and similar principles hold for other interpreted languages - they're effectively object files once deployed, as in any deployment they're being run by the interpreter, not read by a human.)