Why did the technical debt go to therapy? Because it had too many unresolved dependencies!
Every engineering team I’ve worked with has faced the same question: should we refactor this now or push it to later? Technical debt is one of those concepts that everyone understands but few agree on how to handle. I’ve seen teams spend months perfecting code that never ships, and I’ve seen teams ignore obvious problems until they become existential threats. The reality is that not all technical debt is created equal, and knowing when to pay it down versus when to strategically ignore it can be the difference between moving fast and moving nowhere.
Let me start by saying that I’m not here to tell you that technical debt is always bad—or always good. The truth is far more nuanced. Some technical debt is like a high-interest loan that compounds daily, while other technical debt is more like a 0% APR offer that you can ignore indefinitely. The challenge is learning to tell the difference.
Identifying Technical Debt
Technical debt comes in many forms, and not all of it is immediately obvious. I’ve learned to recognise several common patterns:
Obvious debt: This is the kind that everyone knows exists. Maybe it’s that legacy system that’s held together with duct tape and hope, or the code that makes senior engineers wince when they look at it. This debt is usually documented (or at least whispered about in corridors), and the cost of maintaining it is visible.
Hidden debt: This is more insidious—code that works but is poorly structured, documentation that’s out of date, or dependencies that are one security patch away from being vulnerable. This type of debt doesn’t scream at you, but it compounds quietly in the background.
Architectural debt: This happens when you make design decisions that work now but will limit your ability to scale or adapt later. Perhaps you chose a database that works for 10,000 users but will struggle at 1 million. Or maybe you built a feature in a way that makes it difficult to extend. Architectural debt often seems like the right decision at the time, which is what makes it so dangerous.
Process debt: Sometimes the debt isn’t in the code at all—it’s in how you work. Missing automated tests, manual deployment processes, or lack of monitoring can create debt just as real as bad code. I’ve seen teams spend more time fighting fires than building features because they skipped the infrastructure work.
The key to identifying technical debt is developing a sense of what “good enough” looks like versus what “will bite us later” looks like. This comes with experience, but there are patterns to watch for: code that multiple people avoid touching, features that break frequently, or systems that require specialist knowledge to maintain.
Calculating Cost of Delay
Once you’ve identified technical debt, the next challenge is understanding its true cost. This is where most teams get it wrong—they either overestimate the cost (leading to premature optimisation) or underestimate it (leading to crisis management).
Direct costs: These are the easiest to measure. How much time do engineers spend working around this debt? How many bugs does it cause? How much slower is development because of it? I once worked on a codebase where a poorly designed data layer added an extra day to every feature development cycle. That’s a direct, measurable cost that compounds over time.
Opportunity costs: This is trickier but often more significant. What could your team be building if they weren’t maintaining this debt? What features are you not shipping because you’re spending time on workarounds? What business opportunities are you missing because your technical limitations prevent you from moving fast enough?
Risk costs: Some technical debt creates real risk. Maybe it’s a security vulnerability, or a system that could fail catastrophically under load. I’ve seen teams ignore these risks until they become actual incidents, at which point the cost becomes not just time but reputation and customer trust.
Compound interest: This is the sneakiest cost of all. Technical debt doesn’t just sit there—it compounds. Every feature built on top of shaky foundations makes the problem worse. Every developer who learns to work around the problem embeds the workaround deeper into the codebase. The debt that costs you 5% of your engineering time today might cost you 20% in six months.
The framework I use is simple: if the monthly cost of the debt (in engineer time, bugs, or missed opportunities) is greater than the cost of fixing it, you should probably fix it. But if the debt is static—it exists but doesn’t actively cost you anything—then it might be okay to leave it for now.
Strategic Refactoring
Not all refactoring is created equal. The goal isn’t to have perfect code—it’s to have code that serves the business effectively. Strategic refactoring means choosing what to fix based on impact, not just aesthetics.
Fix what’s actively hurting: Start with debt that’s causing problems today. Is there a system that’s breaking frequently? Code that multiple engineers struggle with? A bottleneck that’s slowing down development? These are high-impact fixes that will make a real difference.
Refactor during feature work: One of the most effective approaches I’ve found is to refactor as you build. If you’re already touching code for a new feature, that’s the perfect time to improve it. This doesn’t mean rewriting everything—just making the code you’re working on a bit better than you found it. Over time, this approach compounds into a much cleaner codebase without the big-bang refactoring projects that never seem to finish.
Create technical milestones: Sometimes you need to dedicate time specifically to technical improvement. The key is to do this strategically—choose what to fix based on what will unlock future velocity, not what looks prettiest. I’ve had success setting aside 20% of engineering time for technical improvement, but only if that time is spent on high-impact work.
Measure the impact: After you refactor, measure whether it actually helped. Did it reduce bugs? Speed up development? Make onboarding easier? If you can’t measure improvement, you might have optimised the wrong thing. I’ve seen teams celebrate beautiful refactors that didn’t actually change outcomes—which means they wasted time they could have spent on features.
Know when to stop: Perfect is the enemy of good. I’ve watched teams refactor the same system three times because they kept finding ways to make it “better.” At some point, you need to accept that the code is good enough and move on to building features.
When Technical Debt is Actually OK
This might be the most controversial part of this post, but not all technical debt is bad. In fact, sometimes it’s the smart choice.
Debt that enables speed: Sometimes taking on technical debt lets you ship faster and learn from real users. If you’re validating a product idea, shipping imperfect code might teach you more than perfect code that never ships. I’ve seen startups spend six months building the perfect system for a product that nobody wanted. A bit of technical debt in the early days can be a smart trade-off.
Debt with low interest rates: Some technical debt just sits there. It’s not great code, but it works, it’s stable, and it doesn’t cause problems. Refactoring this might make you feel better, but if it doesn’t improve outcomes, why bother? I’m not suggesting you ignore all technical debt, but if the code works and isn’t actively costing you anything, there might be higher-value work to do.
Debt you’ll outgrow: Some technical decisions make sense for your current scale but won’t work at 10x scale. The question is: will you ever reach 10x? If you’re a small team with uncertain growth, optimising for scale you might never reach is premature optimisation. It’s okay to have code that works for now and might need rethinking later.
Debt that’s cheaper to rewrite: Sometimes the best way to pay down technical debt is to throw it away and start fresh. If a system is so tangled that refactoring would take months, building a replacement might be faster and better. I’ve seen teams spend years trying to fix legacy systems when they could have built something new in six months.
Strategic shortcuts: Not every shortcut is a mistake. Sometimes the quick implementation is good enough for the problem you’re solving. Perfect code for a throwaway prototype is wasted effort. Code that ships and generates revenue is more valuable than perfect code that never sees the light of day.
The key is being honest about whether the debt is a strategic choice or an accident you’re too lazy to fix. Strategic debt is intentional—you know you’re taking it on and why. Accidental debt is just poor engineering, and that will compound until it becomes a crisis.
A Personal Framework
Over the years, I’ve developed a simple framework for deciding what technical debt to tackle:
Is it actively costing us time or money? If yes, prioritise fixing it. If no, it can wait.
Will fixing it unlock future velocity? Some refactoring pays for itself by making future development faster. This is usually worth doing.
Is it creating risk? Security vulnerabilities, systems that could fail under load, or code that’s one wrong change away from breaking—these need fixing.
Can we work around it effectively? If the debt is contained and easy to work around, it might be lower priority than debt that infects everything you build.
What’s the opportunity cost? Every hour spent refactoring is an hour not spent building features. Make sure the refactoring is worth that trade-off.
I’ve found that most technical debt falls into one of three categories: debt that’s actively hurting (fix it), debt that will hurt later (plan to fix it), and debt that’s just ugly but harmless (maybe ignore it). The art is in correctly categorising your debt.
Key takeaways
Technical debt isn’t inherently good or bad—it’s a tool. Like any tool, it can be used well or poorly. The teams that succeed are the ones that learn to take on debt strategically and pay it down when it makes sense, not the ones that either ignore it completely or obsess over eliminating it entirely.
The goal isn’t zero technical debt. The goal is technical debt that serves your business objectives. Sometimes that means taking on debt to move fast. Sometimes that means paying it down to avoid future pain. The skill is in knowing which is which.
Remember: code that ships and generates value is better than perfect code that never sees users. But code that constantly breaks and slows you down is worse than both. Find the balance, make strategic choices, and don’t let perfectionism—or laziness—drive your technical decisions.
The best codebases I’ve worked with aren’t the ones with the prettiest code—they’re the ones where the technical decisions align with business needs, where debt is taken on intentionally and paid down strategically, and where engineers can move fast without breaking things constantly. That’s the sweet spot worth aiming for.