(The Three Physics of Software — part 2 of 2: disposability, and the escape surface)

Left alone, that only goes one way: the codebase accumulates and complexity rises.

Part 1 is the reason it matters.
The same codebase behaves like a heavier object at higher velocity, so the cost per change goes up.
And slowing down does not give it back; the conflicts still need resolving and the understanding still needs rebuilding.

Writing got faster and human capacity did not, so the only viable option is to decrease how much there is to hold.
i.e. reduce the mass.
Deletion is the lever that works on both halves of it: what you remove takes its couplings with it.
Easy to say. So let’s work out what it takes.

Why we never deleted anything

Two reasons.
Sunk cost: it’s psychologically hard (really hard) to throw away a feature that took six months to develop.
Removal cost: Taking out code that was not designed to be taken out takes significant effort. Unwinding it meant rollbacks, migrations, backfills, dependency archaeology.

Both of these costs just moved.
When a feature takes just a day to create using AI, removing it throws away just a day worth of effort, also the removal work is exactly the engineering that got cheap with AI.

Cheap reversal stops at your boundary

This is where “just delete it” stops working, and it is the part the disposable-code conversation usually skips.
Ken Huang does discuss it in Disposable Code, Durable Side Effects:
“The code is disposable. Its side effects are not.”

And while Ken talks mainly about security aspects, this also means Reversibility is cheap up to your system boundary, and has a heavy cost beyond it.
Inside your own schema, your data, your services, unwinding is an engineering task, and engineering tasks got cheap.
Outside, it involves people, contracts and business process, and none of that got cheaper.
Turning a feature off does not un-send the emails.

That asymmetry is the whole point. The cost inside collapsed; the cost outside did not move at all.
Which is why the boundary, not the code, decides whether you can delete anything.

Measuring what escapes

Decreasing mass is a capability rather than a decision, which means it needs a name and a number.

Disposability is how easily mass can be shed.
Your own schema is not why you cannot delete something.
What you cannot unwind is what already leaked outside.

So you measure it from the outside in. Call the thing you measure the escape surface, and treat it the way you treat attack surface:
something you enumerate and design down, not a score you receive.

Take a feature and list what has crossed your boundary:

·        consumers outside your boundary that depend on its interface

·        data that left and is now read somewhere else

·        irreversible effects it emitted: emails sent, payments taken, third-party state changed

·        obligations that outlive it: retention, audit, regulatory

Then ask one question of each item. Can you call it back?
An internal consumer you own, yes, with work.
A partner integration, maybe, over months.
An email that arrived last week, no.
A seven-year retention obligation, no.

One “no” is enough to prevent the entire feature from being disposed.
Everything on the yes side is genuinely disposable, some of it free and some at a price you can quote.

So every feature comes back yes or no, and the escape surface is the share of your features that came back no.

The law that changed

The old law: code is expensive to produce, so protect what you have built.

The new law: code is expensive to keep, so hold as little as you can.

You will object that “code is a liability now” is already close to consensus.
It is, and this goes one step further.
A liability is something you regret owning. A holding cost is something you pay every month you keep it, at a rate set by how fast you are going.
Part 1 measured that rate.
Escape surface tells you how much of the bill you cannot get out of.

The cost moved from creation to custody.

What still holds

Velocity is how fast the system changes.
Mass is how hard it resists being pointed somewhere else.
Disposability is how much of that mass you can remove.

Slowing down is not on the table.
The velocity you can sustain is set by what you can put down:

Velocity ∝ disposability, and disposability ∝ 1 / escape surface

* * *

Part of The Three Physics of Software — what happens to the rules of software engineering when the code stops being written by people.