Software Has No Floor: Why Technical Debt Never Naturally Collapses

Software engineer Zach Kehs has challenged the industry's reliance on physical metaphors to describe technical debt, arguing that code does not behave like a collapsing building. In a recent essay, Kehs posits that software lacks the physical constraints that force a natural reset, meaning systems can degrade indefinitely without ever truly 'breaking.'

Kehs argues that common comparisons to sinking ships or crumbling infrastructure are fundamentally flawed because software exists in an abstract domain. Unlike a bridge, which is subject to gravity and structural integrity, code has no physical limit to how poorly it can perform. According to Kehs, "Software faces no such constraint. The code can always get worse. There can always be a new layer of indirection or a reduction in performance."

The Cycle of Grafted Complexity

Drawing on his professional experience at Amazon, Kehs describes a destructive cycle common in large organizations. He observes that when re-architectures fail, they are often simply grafted onto existing systems rather than replacing them. This process increases both headcount and complexity without addressing the underlying rot.

This environment creates what Kehs describes as "haunted graveyards" of code—sections of a system that become impossible to fully understand as institutional knowledge erodes. In these cases, the system enters a state that Kehs describes as being in a "constant, neverending state of collapse," where the software continues to function despite its internal decay.

The Myth of Software Bankruptcy

While the industry frequently compares technical debt to financial debt, Kehs highlights a critical distinction: software has no true equivalent to bankruptcy. In finance, bankruptcy provides a legal mechanism for a clean reset. In software, however, full rewrites are rarely viable options due to the sheer scale and risk involved.

Because there is no mechanism for a clean slate, organizations often resort to "side-channels," building disconnected systems for new use cases while continuing to maintain the original, degraded core. This prevents a total system failure but ensures that the original technical debt remains a permanent burden.

The Risk of Postponed Maintenance

This lack of a physical "floor" has significant implications for management. The belief that a system will eventually hit a breaking point can lead decision-makers to postpone critical maintenance, operating under the assumption that a future catastrophic failure will finally force a necessary rewrite.

Kehs warns that while a business may eventually fail due to this inefficiency, the code itself will never naturally collapse to trigger a reset. By recognizing that software can degrade infinitely, Kehs encourages engineers and managers to actively manage quality continuously—essentially "grabbing a bucket" to deal with the leaks—rather than waiting for a disaster that may never come for the code.