Tech debt is an outdated concept
Tech debt is often overused as a blanket statement for all manner of engineering issues. What if we reframed our approach?
This article was originally published on LeadDev.com on March 6th 2025. Republishing here as I still believe the language of optionality is crucial for aligning engineering and the wider business, especially in the age of AI.
We need to look beyond the overused term of tech debt, and instead start focusing on “optionality.”
The rapidly evolving engineering landscape is forcing leaders to build stronger bridges with the business. In a time of exceptional change, we need better language to understand one another and collaborate more effectively. This is why it’s time to ditch “tech debt” and start talking about optionality instead.
Tech debt is a misused term
The term technical debt was coined over 30 years ago by Ward Cunningham. It was invented to help business stakeholders in a financial institution understand the costs of not investing extra time and skill in writing high-quality, maintainable code.
Since then, “tech debt” has become ubiquitous in the technology industry. In my experience, it is also one of the most frequent points of disagreement and tension between engineering and the rest of the business.
I’ve lost count of the number of times I’ve needed to explain what tech debt “actually” means. I’ve also frequently encountered distrust from product managers, executives, and founders when invoking tech debt as a justification for spending time on activities that don’t have an immediate business impact.
It doesn’t help that engineers frequently disagree on what tech debt is. But it’s also important to acknowledge that the haziness around the definition of “tech debt” can serve insular engineering interests. Too often, it can be invoked to justify fixing things that engineers find annoying while deflecting accountability or scrutiny from non-technical stakeholders. Of course, there is value in tidying up messy code, updating old packages, and restructuring our services, but simply lumping them all together as tech debt obscures their value.
Optionality as a new metaphor
I first came across the concept of optionality when reading Kent Beck’s seminal Tidy First? A Personal Exercise in Empirical Software Design.
Optionality, like tech debt, comes from the world of finance. Specifically, it relates to the idea of “call options,” where you have the right (but not the obligation) to buy a product or good in the future at a fixed price.
One of the key insights of optionality is that flexibility is valuable. Not only that, but the greater the uncertainty, the more valuable that flexibility is. To illustrate this, think of booking train tickets.
Often, you can pay more to have an “open” ticket, which allows you to transfer to a different train at little to no extra cost. A small markup is reasonable, but a steep hike? An unlikely investment.
But let us now imagine that on the day you are due to travel, disruptions are likely. Strikes are planned. The friend you’re travelling with is notorious for showing up late. Suddenly, the prospect of being able to jump onto any train, even at such a high extra cost, looks more and more like a bargain.
Fundamentally, optionality allows for easier system changes, lowering the chances of any unnecessary lifting. What makes software easier to change? Clear and easy-to-understand code, robust test suites, strong deployment pipelines, extensible architecture, high-quality documentation, and above all, aligned and cooperative teams of engineers.
These abilities are even more valuable in highly volatile environments, where things are unpredictable, and we simply don’t know what we might need tomorrow.
Why optionality?
Optionality doesn’t just provide a metaphor to aid in how we communicate with those outside of engineering, I believe it also helps clarify our roles as engineers.
My last full-time role was at a fintech start-up whose core product was a financial prediction dashboard. The app was a mess: spaghetti code, no tests, no documentation, and an arcane and bug-prone deployment process. Most of the people who had created it were no longer there. Making even small changes was slow, painful, and fraught with danger.
It was time for a rewrite. Everyone wanted to burn the old app, including me. But that didn’t take away from the fact that the old app, no matter how imperfect, had been successful enough to help the company get to the next level.
When we brought in the new architecture and applications, we noticed an improvement in terms of UI and UX, but the real value it delivered was how quickly it could be changed and adjusted. With independently deployable micro-services and micro-frontends, the company could now scale to add new products as fast as the market demanded.
When I joined the company, they had one live product. When I left after 18 months, four products had been deployed. A little over six months after that, and they’d added another ten. But the value we’d created as engineers was not when those new apps were deployed – it was when we first changed the software to make those deployments easier.
Optionality isn’t always the best policy
As engineers, our default is to focus on increasing optionality. Making software easier to change through good design and best practices not only fulfills our sense of professional pride; it makes our lives much easier. But focusing only on long-term adaptability and ignoring immediate value can be a mistake.
The best service I’ve ever built was also my biggest failure. While leading a team to integrate third-party software into a mental health counseling system, we designed a well-architected anti-corruption layer (ACL) to ensure robust integration. Clean architecture. Functional programming. A complete end-to-end test suite. You name a “best practice” – we were doing it.
We worked on it for almost a year. Then the project got scrapped. Nothing saw the light of day.
There are many reasons that contributed to the project being canned. Still, it’s important to ask – could we have done more to deliver value faster? Should we have prioritised getting something into the hands of users over doing things “the right way”? I believe so.
The lesson was clear: perfect code that’s never used is perfectly pointless. Designing a system to be ready for a tomorrow that never comes is a waste. Sometimes, we need to hack to simply survive. Fixing it later is a blessing – it means we made it.
Final thoughts
If engineers are cultivators of optionality, this role will become more crucial – not less – in an age of AI-generated code and applications. Creating software that delivers value to users today has never been easier, and will only get cheaper. But making sure that software is robust, extensible, and simple to work with, so that it can produce greater value in the future than it currently does today? That still requires engineers to cultivate the optionality of software.
But with this role also comes the responsibility to understand when it’s appropriate to invest in future value, and when it’s not. To be honest about the impact of a change, and to rigorously consider it not just from our personal perspective but from the wider business perspective too.
This will require a shift in mindset for many engineers of all levels. It will require a deeper engagement in the wider business context, a more holistic approach to building software, better communication outside of engineering departments, and more collaboration.
It’s time to refactor our language, and embrace optionality.
I agree that the term is overused and misused, but I don't think it's outdated.
I'm not an engineer, but for what it's worth, if anyone asks me to explain what I mean by technical debt, then I say it's the outcome of either (1) the gap that emerges when our understanding of a domain or solution evolves beyond our original implementation; or (2) the intentional, deliberate trade-offs we make to meet business goals (including to learn or validate, not just release stuff).
I'd see the idea of optionality as helping to reduce the cost of repaying technical debt (when required) under the first of those scenarios. (If you're already making trade-offs under the second scenario, you probably won't be afforded the means to buy the option.)
As you say, an option gives you the right, but not the obligation, to buy a product or good in the future at a fixed price. The problem comes when as an engineer you feel you have an obligation, but the wider business doesn't give you the right.
You took an unexpected turn for me. I thought you'd talk about how incurring tech debt is an option, and then I read a post about how we need to design for optionality.
Did I miss something? Tech Debt may, or not, remove optionality, but it provides (sometimes) a way to get a certain return (to market first, no need to hire expensive consultants, etc.).
So, now I'm left with the question: how would you frame optionality related to tech debt instead of architecture?