The IAD Tech Debt Analogy is something that emerged after many years at many companies. Each had felt real pressure and pain in trying to build upon tech debt. Addressing tech debt always comes while trying to balance forward progress for the business. Removing or changing existing code, without breaking existing functionality or edge cases, needs to be approached with the caution of diffusing a landmine.
This IAD Tech Debt Analogy emerged from years of watching teams struggle to overcome hidden risks embedded in long‑lived systems.
It reframes technical debt as volatile, historically constrained systems that demand observation, restraint, and stewardship rather than cleanup.
Why the IAD Tech Debt Analogy Matters
Each pocket of tech debt was built years ago, in a different basement, by a different self taught anarchist. Each anarchist, at the time code was created, was fighting for a real cause. There was a very real battle to be fought to address a need, under constraints that made sense then. Those reasons may no longer be fully appreciated – much like Chesterton’s Fences.
And just like those fences, most of these IADs weren’t built out of carelessness or chaos. They were built under pressure. They were built by people doing the best they could with the constraints, timelines, and partial information they had. What looks irrational now was often the only rational move available then. Remembering that keeps us humble.
Some of those builders are still around but don’t fully remember how or why certain wires were twisted. They don’t recall if the red or green wire is the live wire. Others have long since moved on, and what remains is the device itself. It’s still live, still volatile, still connected and doing something important, but with intent that may be forgotten or misunderstood.
Thriving Businesses on Old Foundations
Now imagine these IADs are embedded deep in the basement foundation of a building we’re actively adding to. They can’t be safely removed. We can’t evacuate the building. People live and work above them, and their livelihoods depend on the structure staying intact.
So the question, case by case, isn’t how do we clean this up? It’s “do we leave this IAD alone because it’s stable and can be avoided, or do we carefully diffuse it? Trying to make that decision while knowing we can’t fully predict what it’s connected to, triggered by or keeping alive?”
Context Is the Real Cost
This is the heart of the IAD Tech Debt Analogy. Every device carries history, constraints, and unintended consequences that only reveal themselves under careful observation. If caution is not exercised in diffusing the landmine before it’s stepped on, collateral damage may result.
That’s why all the experience in the world doesn’t give us a universal recipe. What it gives us is the discipline to observe first. This can be achieved by instrumenting, inferring constraints from behavior, and reducing blast radius. It’s also prudent to make changes reversible, and let runtime truth earn confidence before anything structural is touched.
However, the largest cost of any change is not writing code. It is gaining enough context to understand what the device is doing. Engineers pay this cost whether they add a feature or clean up debt. They read code, trace behavior, and reconstruct past decisions.
Because of this, timing matters. When a team adds functionality in an area with technical debt, context is already loaded. That moment often offers the lowest additional cost to address related debt safely.
Likewise, when engineers clean up code in a specific area, context is fresh.
That same moment can support a meaningful product improvement with little extra overhead.
Therefore, separating feature work from debt work tends to increase total cost.
It forces teams to repeatedly reload the same context. In contrast, combining the two can reduce risk and effort. Engineers already understand the device they are touching.
The key is intent and restraint. Teams should not expand scope carelessly. They should make small, deliberate improvements while context is present. This approach does not encourage reckless cleanup. It encourages thoughtful stewardship while understanding is at its peak.
The Hidden Advantage
There is another advantage to this approach. It improves code in the areas where change already occurs. These areas are often the most volatile and the most valuable. As a result, improvements land where they matter most. They support active use cases and real user needs.
In addition, this reduces friction for future change. Teams make progress in areas they already understand.
By contrast, addressing an IAD far from active work delivers less value. Context is stale, usage is lower, and risk is harder to justify. Therefore, prioritizing change where work already happens often yields better outcomes. It aligns effort, understanding, and impact.
Enter the AI-Enhanced Bomb Disposal Robot
At some point, new tools enter the picture. In recent years, that tool has been AI.
Continuing the analogy, AI is best understood not as a replacement for bomb disposal experts, but as the latest generation of bomb disposal robots. These tools can see more than a human can see, reach places a human cannot safely reach, and explore possibilities far faster than a person ever could. They can trace deep dependency chains, surface hidden couplings introduced years ago, and simulate the potential blast radius of a change before anything is touched.
Used well, they make experts more capable and safer.
Used poorly, they simply accelerate mistakes.
The crucial point is this: even the most advanced bomb disposal robot does not know which wire truly matters, which signal is noise, or which odd-looking connection is actually protecting something vital. It does not understand the history of the battle that led to the device being built. It knows nothing of tradeoffs made under pressure, or the consequences of being wrong in a lived environment.
That understanding lives with the expert.
AI extends perception and reduces cognitive load, but it must be guided deliberately by someone who understands the domain, the risks, and the stakes. The more powerful the tool becomes, the more it depends on human judgment to be used responsibly.
As with the IADs embedded in the foundation, the goal is not speed or cleverness. It is safety, understanding, and reversibility. The expert still decides when to act, when to pause, and when a device should be left untouched.
Not for the Faint of Heart
Every IAD demands that balance. It requires enough fear to stay alert, no panic that clouds judgment, and zero complacency about the risks that accumulate.
Seen through the IAD Tech Debt Analogy, the work becomes less about cleanup and more about stewardship. Knowing what to touch, what to leave alone, and what must be understood before anything moves is vital.
Getting it right comes with a responsibility not to be sneezed at. Yet, leaving them all alone is also not an option. It seems a fitting case for my theory that:
- Fear is Healthy.
- Panic is Deadly.
- Complacency Leads to a Quiet Death.
See Also
Tech Debt – Atomic Rituals
This page reframes technical debt as an accumulation of invisible commitments and deferred decisions rather than a cleanup task. It complements the IAD Tech Debt Analogy by focusing on intentional practices that prevent reckless rewrites and encourage discipline.
Handling Interrupts Without Losing the Plot – Talent Whisperers
This article examines how constant interruptions erode situational awareness and increase error rates in complex systems. It directly supports the analogy’s argument that safe change requires sustained attention, context preservation, and protection against reactive decision-making.
The Software Development Life Cycle – Atomic Rituals
Explores the SDLC as a living system rather than a linear process, emphasizing feedback loops, reversibility, and learning over rigid stage-gates. It aligns with the IAD Tech Debt Analogy’s view that safe evolution depends on observation, instrumentation, and controlled change.
Against All Odds – Learning Under Extreme Conditions – Talent Whisperers
My journey exploring how it came to bethat through 11 companies.All had significant tech debt, all faced existential crises. Yet, all managed to survive and 7 achieved billion-dollar-plus valuations. It looks at how clarity, focus, and learning emerge under extreme pressure.
Weathering Storms – Talent Whisperers
Explores critical ingredients to startup success. It’s not the fastest ship that wins the race, it’s the one that can weather the storms. In fact, rough seas make for good sailors.
Chesterton’s Fence – The Principle of Inherited Constraints
“Chesterton’s fence” suggests reforms should not be made until the reasoning behind the existing state of affairs is understood. The quotation is from Chesterton’s 1929 book, The Thing: Why I Am a Catholic, in the chapter, “The Drift from Domesticity.” Chesterton’s Fence is a foundational principle behind respecting existing structures before removing or altering them. It provides the philosophical lineage for the IAD Tech Debt Analogy, reinforcing why unexplained complexity often encodes hard-won constraints.
Technical Debt – Martin Fowler
Martin Fowler’s writing clarifies the difference between deliberate, strategic technical debt and accidental or reckless accumulation. His work provides a widely respected framework for discussing tech debt without defaulting to cleanup narratives.
Working Effectively with Legacy Code – Michael Feathers
This book is a foundational text on making changes safely in large, poorly understood systems. It strongly reinforces the IAD Tech Debt Analogy’s emphasis on characterization tests, constraint discovery, and earning confidence before refactoring.
Building Secure & Reliable Systems – Google SRE
This book explores how complex, high-risk systems are evolved safely through observability, staged change, and fast rollback. Its approach aligns closely with the analogy’s focus on blast-radius reduction and operational discipline.