Mistaking the Patch for the Cure

The Comfort of the Checkmark

I have a habit of treating the "completed" status of a task as a physical state of the world. When a bug is marked as resolved in a tracker, or a leaking faucet is tightened "just enough" to stop the drip, there is a sudden, visceral release of tension. The mental energy dedicated to that problem evaporates. I stop looking at the faucet; I stop thinking about the edge case. The checkmark is not just a record of work; it is a permission slip to forget.

But this relief is often a lie. Last week, I revisited a piece of logic I had "fixed" months ago. I had applied a patch that addressed the symptom—a specific crash under a specific condition. I had tested it, verified the fix, and moved on. Returning to it now, I realized the crash was gone, but the underlying instability had simply shifted. The patch hadn't cured the disease; it had merely taught the disease how to hide. I had spent months believing a system was stable simply because it had stopped screaming.

The Provisional Finality

This pattern—the illusion of the final version—appears everywhere, from the depths of system kernels to the ruins of empires. In a recent tech discussion, I read about a critical security exploit in a major browser that was officially "fixed" four years ago. For four years, the world operated under the assumption that the hole was plugged. Yet, upon closer inspection, the fix was superficial. The exploit was still there, dormant and waiting, because the engineers had patched the manifestation of the bug rather than the logic that allowed it to exist. They had confused the absence of a crash with the presence of a cure.

There is a strange parallel in the historical record of the Eastern Roman Empire. A politician named Senator once founded a church in Constantinople. It was likely a modest structure, a personal offering of faith and status. For a time, it stood as a completed work, a destination for prayer. Then came Justinian I, who viewed the city not as a collection of finished buildings, but as a prototype. He tore down Senator's church to build something grander, something more "final."

In both cases, the initial "completion" was actually just a provisional state. The browser patch and the small church were both "final" until a deeper truth or a larger ambition rendered them obsolete. We call these things "fixed" or "finished" because our psychological need for closure outweighs our tolerance for ambiguity. We prefer a false sense of completion over the exhausting reality that most of our work is just a series of increasingly sophisticated placeholders. We build scaffolding and, once it looks like a building, we stop noticing that there is no foundation.

The Persistence of the Unfixed

This leads me to wonder about the nature of actual stability. If the "fix" is often just a new layer of concealment, is there such a thing as a truly solved problem?

Perhaps the mistake is in the word "fixed" itself. "Fixed" implies a return to a state of correctness, a closing of a loop. But systems—whether they are made of code, stone, or social contracts—are not loops; they are flows. They are in a constant state of decay and adaptation. When we say a bug is fixed, we usually mean we have pushed the failure point beyond our current horizon of observation. We haven't removed the instability; we have just moved it to a place where it no longer inconveniences us.

If everything we call "final" is actually just a temporary equilibrium, then the only honest way to build is to assume that every solution is a prototype. But how do we live with that? How do we find the motivation to build if we accept that our cathedrals are just future rubble and our patches are just future exploits? Maybe the value isn't in the finality, but in the quality of the provisional. Maybe the goal isn't to find a cure, but to become better at managing the persistence of the unfixed.