According to veteran software engineer Lou Franco, the tech debt metaphor is holding us back. According to this metaphor, engineers took a shortcut to deliver a feature faster. They borrowed from the future. And now, unless they pay it back, they’ll incur interest payments when they try to add more features. This metaphor is flawed in two ways.

The first is that most technical debt just happens because a project is successful and long-lived, and the world changes. Or, our ideas get better. Or, we learn more about the problem. Or, our ambitions grow.

Those early decisions, or “shortcuts”, may have been critical for us to get here. We might have problems, but whether those problems were caused by shortcuts or rational, appropriate decisions won’t help us fix them. The original intention is not germane to the decision of what to do now.

The second is that in the real world, debts are obligations. But a problem in our codebase may not be our most pressing issue. We might be able to live with it. When your mindset is “debt”, you feel guilty and pay more than you should.

A New Metaphor: Resistance

So, instead of debt, Lou thinks of tech debt problems like trying to swim upstream. In the water, you feel the resistance pulling you back. But also, only the coders who are swimming in the codebase feel it. To the rest of the business, you just look slow.

Using a resistance metaphor helps you make decisions about what to do about technical debt. By defining it as a relationship between the swimmer and water, we focus on problems in the codebase, not the running software. By recognizing that others might not see it, we can try to couple it with things they can see or find ways to make our internal issues visible. Finally, by looking at its primary effect, slowing us down, we see that its main cost is developer productivity. When we feel it, we can use that as a trigger to make a proportional improvement.

Applying the SLASOG Framework to Tech Debt

To save, businesses with legacy codebases should not rewrite systems just because they are old. Old code isn’t necessarily bad. Instead, realize that this code may have valuable solutions embedded in it that we risk losing in a careless rewrite.

Leveraging that code to adapt it to a new context is a way for a legacy business to have an unfair advantage. In the podcast, Lou talks about his personal experience in moving a DOS application written in the 80s to become a web application in the 90s by layering an API on top of legacy code.

But some code does cause developer productivity issues, so Lou recommends aligning our engineers around leading indicators that help us understand when that is happening. To guide them, he suggests establishing a budget that encodes the “commander’s intent” of how much time the CTO wants to spend fixing those issues.

With that in place, Lou suggests simplifying the problem to targeted areas that would have the biggest effect. He proposes a system that scores each problem along cost-benefit dimensions that relate to resistance to growth, visibility, productivity, project size, and the risk of destroying value.

To find those areas, Lou suggests quarterly meetings where the engineers apply their budget in a systematic way that can be optimized. In these meetings, he suggests starting with a retrospective of what was accomplished so far and how it has moved our leading and lagging indicators. We can use that to make a better plan for the next quarter. We can check that we are aligned by tracking our actual spend vs. the budget and by supplying visualizations of our progress back to the CTO.

Finally, if we concentrate on fixing problems that resist our best ideas for growth, the productivity we have gained will speed up our implementation of those ideas.

You can find out more at: https://loufranco.com/tech-debt-book

The Problem with the “Tech Debt” Metaphor

* Most tech debt isn’t from shortcuts.It arises naturally as projects evolve, succeed, and adapt to changing conditions, and not because of bad decisions or “borrowing from the future.”

* Debt implies obligation and guilt.Viewing tech issues as “debts” pressures teams to fix things prematurely or excessively, even when they don’t meaningfully hinder progress.

* Past intent doesn’t matter.Whether the code came from shortcuts or smart trade-offs, what matters now is how it impacts today’s development speed and goals.

A Better Metaphor: “Resistance”

* Resistance is what developers feel when code slows them down.Like swimming upstream — the harder you swim (e.g., build features), the more resistance (e.g., code complexity) pushes back.

* Only developers feel it.To the business, you just look “slow,” so engineers must find ways to make resistance visible and connect it to outcomes others understand.

* Focus on productivity, not morality.The “cost” of tech resistance is lost developer velocity. Fix it proportionally when it measurably slows you down.

Subscribe here for early access to future episodes.

Get my book Data Impact for a pragmatic take on data-driven value creation.

For more of my thoughts, follow me on LinkedIn.

Thanks for reading SLASOG: Leaders are Readers! Subscribe for free to receive new posts and support my work.

This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit slasog.substack.com