This assumes all things can be usefully viewed through the prism and language of economics (though my gut feel is few things can or should be).
This assumes all things can be usefully viewed through the prism and language of economics (though my gut feel is few things can or should be).
Making progress in the world is fighting against entropy. Just because it is hard to fight the disorganizing efforts of the universe doesn’t mean that your output is a liability.
> liability: a thing for which someone is responsible, especially a debt or financial obligation.
According to the balance sheet equation,
> Assets = Liabilities + Owners Equity
Certainly all code is a liability - it must be at least understood and maintained from time to time (80% of lifetime cost is in the maintenance).
And while an accountant might also mark it an asset - not all code is an asset - and we recognize that fact when we delete for badness or disuse - or rewrite it to make extending and maintaining it easier.
I'd accept that debts are a subset of liabilities, but not that 'liabilities are debts'.
A debt implies an externality, while a liability implies some generic exposure -- it's that which I focus on when considering (all) code as a risk to an organisation.
I suspect, however, that we agree on the fundamentals. There's some cost and risk to developing and trying to maintain any code base, and accepting that can usefully inform development and operations work better than thinking of code as a (near-)risk-free asset.
I used to program COBOL on IBM 370 DOS/VSE systems they later went to Visual BASIC on Window 3.1 PCs. The conversion took a long time and most code had to be rewritten because COBOL is not BASIC. Management didn't care about that, they just wanted a working project. We all did our best going overtime without pay and working weekends to meet deadlines.
COBOL was a liability when they wanted to convert to Visual BASIC. There was liability to convert the code, convert from DB2 to SQL Server on the database end.