> working code requires ongoing maintenance

I don't love this either because working code needs no maintenance whatsoever. After all it's already working. There's also no notion of "repairing" code because it isn't something that can just break suddenly.

So really what we're talking about is that necessary changes to the codebase can arise from not just the stakeholders as we typically define them but also because the environment around the code changes.

Someone who invested in shutters that can close instead of being purely decorative will be able to adapt more quickly and cheaply to a wind storm than someone who has to go out and buy wood to board them up.

Changes to the platform or dependencies break working code. This is increasingly hard to ignore when app stores stop vending your product to older versions of a platform, even if it's working fine.

And working code, no matter how well it works, imposes a cost to implementing new features. A new feature might be a cinch to implement in a new app. But it can easily take much longer to implement the same feature in an existing app.

> Changes to the platform or dependencies break working code

Not all code. You have platform dependent code and then code that doesn't depend on anything outside of your own code. The code with no outside dependencies can easily stay around unchanged for decades and is not a liability.

"All dependencies are liabilities" I could agree with. Dependencies are technical debt that will continue to demand interest from you, they are often worth it but they are the main source of maintenance burden. Some are unavoidable if you need to interface with an API, but many are not.

Unless you're deploying your code bare-metal on a machine with no OS, you've got software dependencies, and even in that situation you've got hardware dependencies. I think the idea of dependency-free code is a myth that we like to use based on the abstraction layers we're comfortable with - if I'm okay assuming that a given layer always Just Works™, then it magically stops being a dependency and becomes the new ground level.

That said, I agree that it's helpful to think of dependencies in terms of their potential liability as well as their benefit.

I use the term liability because the only code that has zero maintenance cost is code that doesn't exist.

If you have a viable solution to a problem that doesn't require code, then you still get the value from that solution without the burden of maintenance.

Classic case in point: your in-house infra platform on K8S is an incredible liability no matter how much value it adds, because it's a means to an end for scaling and serving your product. Or a cost-centre, in other terms. You could just as well host on a collection of SaaS and offload a large portion of the maintenance cost onto the provider.

Rather than writing code that is easy to maintain (read: easy to keep), it's optimal to write code that is easy to discard. The latter is a lot more challenging than piling on architecture and in some sense it's akin to having illiquid code (stuff you can't get rid of very easily), and liquid code (stuff you can get rid of easily).

I'm objecting to the use of the term 'liability' because in accounting/finance in particular, a liability is strongly implied to be a net negative once you weigh all the benefits and costs together.

Here you're saying code is a liability because it has costs. But a car or a house have costs, yet they're almost always classified as assets, because the benefits outweigh the costs.

So you're left with a few choices:

1. Accept that code isn't always a liability, at least according to the dictionary definition of the word

2. Argue your way somehow to code nearly always being a net cost (seems unlikely, otherwise why write code?).

3. Redefine the meaning liability for this particular application

I think 1) is the most reasonable choice here.

‘All code is a liability’ some code is productive.

Different domains have different jargon. Code doesn’t map very well to finance because the loan is also the productive asset. It’s easy for a deprecated function to exist which literally nothing calls and therefore it provides you zero benefits, but such cruft is still an ongoing cost. Meanwhile that exact same function was critical last week.