Introducing Abstraction Deviation Impedance
The Search for a Better Term
Over the years, leading teams and advising executives, I’ve often used “technical debt” to describe those persistent issues that slow us down or make changes risky.
I loved the analogy at first, and it felt like an effective way to flag problems in our codebases or designs. But after countless discussions with developers and stakeholders from all backgrounds, I realised the term creates more problems than it solves.
That’s why I’ve been working on a different way to frame these situations: Abstraction Deviation Impedance.
Why “Technical Debt” Falls Short
Let me explain why “technical debt” doesn’t work well.
The word “technical” suggests the problems are rooted in the technology itself, be it the code, our tools, or the way the infrastructure works. In my experience, though, the real issues often lie in our models and abstractions: how we’ve conceptualized the domain, structured components, and managed complexity. These aren’t just tech issues; they’re about how well our conceptual models align with business needs and their operating environment.
The “debt” part is even more problematic. It implies something borrowed deliberately, like a loan to gain speed now with a plan to repay later. That metaphor sounds strategic, which is why it’s appealing, but it lets teams off the hook too easily. I’ve seen developers use “technical debt” to justify any mess they’ve made or dire state the system is in, framing it as a considered business strategy or calculated risk when, often, it was just neglect, rushed work, a lack of clarity, or a failure to adjust to moving needs.
In reality, these issues usually emerge unintentionally and undetected, from evolving requirements and small oversights that snowby. It’s rarely a calculated trade-off, and the business is often unaware.
Unlike a loan with predictable interest, these issues create unpredictable risks and costs.
In Defence of Technical Debt
In its defence, the term “technical debt” was never meant to be used the way people frequently use it these days.
However, the damage it causes is real.
With its analogy with financial debt, which fuels growth and can be a solid decision if you plan to repay it, people use “technical debt” to justify a perpetual state of short-term thinking and tactical solutions.
Abstraction Deviation Impedance isn’t here to replace Technical Debt entirely. That term still works for deliberate, short-term trade-offs where you knowingly take on a cost.
The new term addresses a broader, often unintentional situation where the system’s abstractions have drifted, creating persistent friction no matter how we got there. It’s about describing the state of a system when the challenge isn’t just repaying a loan but navigating an ongoing, systemic drag that no one signed up for.
Defining Abstraction Deviation Impedance
So, what is Abstraction Deviation Impedance? Let’s break it down.
Abstraction: The Core of Software Design
“Abstraction” refers to the simplifications we create to manage complexity, including domain models, APIs, and data structures.
These are the mental and architectural frameworks that make our systems understandable and adaptable.
When done right, abstractions enable smooth delivery and evolution, aligning closely with what the business needs while remaining capable of reacting to changes.
Deviation: The Gap Between Ideal and Actual
“Deviation” captures the difference between the ideal and the actual.
The ideal is a set of abstractions that perfectly reflect the problem domain: clean, consistent, and easy to extend.
In practice, deviations show up in many ways. Sometimes, it’s incorrect modeling from the start, like a payment system that assumes fixed transaction types and chokes on new ones.
Other times, it’s a gradual drift, where quick fixes or patches pile up, twisting abstractions into something convoluted.
Or it could be moving operating conditions, like a new user patterns or compliance rules, that leave once-fit models outdated.
This gap isn’t about pointing fingers; it emerges through iterations, team changes, or shifting priorities.
It’s the distance between what we envisioned and what we have, and this distance creates problems.
Impedance: Resistance to Flow
“Impedance” is what I find most compelling.
In electrical engineering, impedance measures how a circuit resists the flow of current.
In software, it describes resistance to the flow of value, whether that’s delivering features, incorporating feedback, or scaling operations.
When abstractions deviate from the ideal, every change meets more resistance: debugging takes longer, onboarding new people gets harder, and small updates risk unexpected side effects.
This isn’t a one-time hit but a constant drag that raises costs, increases risks, and can frustrate teams as their efforts feel stuck.
Nothing is Perfect
Abstraction Deviation Impedance not only describes the problem well, but invites people to ask the right questions and discuss interventions.
It’s not a perfect term, but it captures the nuances I’ve grappled with over years of building and maintaining software.
It sidesteps the trap of dressing up messy systems as smart borrowing and focuses on the structural reality we face.
If you’re wrestling with similar challenges and struggle to convey the danger of the situation, try it in your next roadmap discussion or retrospective.
Let me know how it resonates, I’m curious to hear your take.