The Tech Debt Trap (And the Rewrite Trap That Makes It Worse)

If you've ever been to Boston, you know we've got a lot of old stuff. About 20 years ago, I bought a condo in a 120-year-old building. The toilet wouldn't flush very well. Old toilet, old house -- I figured I'd just replace it. Bought a new toilet, had it delivered, plumber showed up.

He took one look and said, "I can't do this."

What I hadn't noticed was that the toilet was mounted below the level of the floor, set into concrete. His ballpark guess to actually replace it? $25,000.

A couple years later, we finally tackled it as part of a bathroom renovation. The quote wasn't $25k anymore. It was $50k for the bathroom and another $50k for the kitchen. To fix the toilet, you had to replace the bathroom floor. The bathroom connects to the kitchen, so that floor had to go too. Replace that floor, now you have to deal with the walls. Fix the walls, now you have to fix the ceiling -- which turned out to be not one drop ceiling but two drop ceilings stacked on top of each other.

Over 120 years, no one had ever done an actually good job at fixing anything. Rather than deal with the original crumbling ceiling, someone put in a drop ceiling. When that got too gross, they just put in another drop ceiling.

That's technical debt. A thousand little bits of not-quite-done. Bandaid fixes on top of quick repairs held together with duct tape. And when you try to fix it, every layer exposes another layer.

Your Boss Doesn't Care (Until You Translate It)
Here's the problem: developers feel technical debt every day. It's the friction that makes simple changes take forever. But when you tell your manager "we need to address our technical debt," their eyes glaze over. It sounds like gold-plating. It sounds like developers wanting to play with shiny things instead of delivering business value.

You're speaking different languages. Technical debt is absolutely a business problem -- but you have to translate it:

• It's a delivery speed problem. Features that should take a week are taking three weeks because every change requires working around existing problems.
• It's a predictability problem. You can't give reliable estimates because you keep discovering hidden problems mid-development.
• It's a quality problem. You're shipping bugs because the code is so tangled that it's hard to test and easy to break accidentally.
• It's a people problem. Your best developers are frustrated and talking about leaving because working in this codebase is miserable.
• It's a risk problem. There are parts of your system that only one person understands, and if they leave, you're in serious trouble.

Those are business problems. That's money. That's what gets leadership's attention.

The Trap Within the Trap
When technical debt gets bad enough, something predictable happens: someone suggests a rewrite. Start fresh. Clean slate. Do it right this time.

It sounds so reasonable. You have deep knowledge of the business problem. You have proof the problem is solvable -- the existing app. You have a team that built or maintains the current version. How hard can it be?

This is the rewrite trap, and it's a hubris factory.

All that knowledge creates false confidence. The team feels like they understand what they're building, so they skip the discipline they'd normally apply. Stakeholders check out -- "just look at the existing application and build that." Developers come up with wildly optimistic timelines. "We built this thing before, how hard can it be?"

And then there's the scope problem. Rather than go through the hard work of deciding which features actually matter, everyone agrees to "just build it all." Who wants to tell Gladys in Accounting she can't have her export to Lotus 1-2-3 feature anymore? She's so nice. (Also she's married to the CEO, so whatever Gladys says goes.)

The rewrite gets loaded down with every feature someone asked for a decade ago -- features nobody knows if anyone even uses -- plus all the new stuff. You're not building a lean, modern application. You're recreating the bloat in newer technology.

Rewrite projects take longer than expected (always). They cost more than budgeted (always). And there's a real chance they fail entirely, leaving you with two half-broken systems instead of one.

The Escape Hatch
So what do you do when you're drowning in technical debt but a rewrite is a trap?

You turn the oil tanker around. Slowly.

Start writing unit tests. Yes, I can already hear you: "But our app is a giant untestable monolith!" It's hard, but it's not impossible. And compare that level of effort to rewriting the whole application.

Every new feature gets unit tests. Every bug fix -- before you fix it, write a test that fails, then make it pass. Every line of code you touch gets a test.

It won't be fast. It'll be like an oil tanker doing a three-point turn. But give it a year. The parts of the codebase that have tests will be easier to change. Developers will be less afraid to touch them. Bugs will get caught earlier. The testable parts expand while the untestable parts shrink.

And here's the key insight: by adding tests for code that has to change, you're investing in the right places. You're not randomly fixing tech debt -- you're fixing the tech debt in the places the business thinks are important. That's a much easier sell.

It's not glamorous. But it works. And it doesn't require betting the company on a multi-year rewrite that might not even succeed.

Learn More
I've written more extensively about the full business case for technical debt -- including what actually works and what doesn't -- and why rewrite projects fail so predictably on my blog.

The question isn't whether you have technical debt. You do. The question is whether you're going to keep putting drop ceilings on top of drop ceilings, or whether you're going to start actually fixing things.

About the Author

Posted by Benjamin Day on 01/21/2026