Zero Tech Debt is a Lie
The aim of some engineering departments has been relayed to me as “zero tech debt”. It’s an aim that is desirable and utterly unrealistic.
Here’s the absolute truth: tech debt is an inevitable part of software development, and not inherently evil. I’d say it’s actually necessary in a functional software development process.
So here is what’s going on, and a better approach than some “zero tech debt” fantasy.
Design or Neglect?
Tech debt takes two forms: deliberate and accidental.
Deliberate tech debt is the equivalent of using a credit card for a sudden expense that you understand will need to be paid back eventually. It’s not ideal, but there are some situations where you need to use this facility.
Then there’s accidental tech debt. You know the type, forgotten corner cases, sloppy code, or “we’ll refactor later” promises that age like milk. This is a problem because this is the type of tech debt that we might not even identify as present. It’s the type of code that clowns create, and push to production.
Accidental debt often arises from short-term thinking — optimizing for “right now” instead of “what will break in six months.” Ironically, the very term “debt” implies you’ll manage it, but most teams don’t.
Piling on debt like a shopaholic during Black Friday sales is bad for everyone. The ultimate cost is burnt-out developers, missed deadlines, and frustrated users.
Chasing Tech Debt == Zero is Counterproductive
Here’s where “zero tech debt” becomes actively harmful. The job of a software engineer isn’t absolute perfection, since even if such a thing existed who would define it?
This means a culture of zero tech debt is often superficial. Alphabetizing imports, splitting functions just to follow arbitrary standards, or rewriting working code for no tangible improvement and the resulting burnout.
The attempt at perfection can mean meaningful issues — like user bugs or system bottlenecks — fester as these is typically more difficult to solve.
Chasing zero tech debt? You’re probably looking at solving the wrong problem.
The Wrong Solution: “Let’s Rewrite Everything!”
A complete rewrite might solve some tech debt issues. Managers and devs often salivate over the idea, picturing a pristine, debt-free codebase that looks like a greenfield project. Spoiler alert: this rarely works for existing projects. Rewrites almost always take longer, cost more, and result in a different pile of debt that comes back to bite the team later.
At one company I worked for, a new manager wanted to rewrite our whole project because their friend recommended a new framework. The result? Months were lost while devs wrestled with development they no longer understood.
A Better Approach: Manage It Like Real Debt
The better path? Acknowledge tech debt as part of your process.
Make Interest Payments
Dedicate time in each sprint to address the highest-impact areas of tech debt. Don’t aim to erase it all, just keep it from snowballing.
Refactor With Purpose
Only refactor when there’s a clear user or developer benefit. Clean code is great, but working code that solves problems is better.
Be Honest About Costs
Decisions like “we’ll fix it later” should be documented and regularly revisited. Future developers (and your sanity) will thank you.
Don’t Penalize Small Messes
A function with a little duplication isn’t the apocalypse. Over-optimizing every line wastes precious time. Get things into perspective, and realize that your work is really about delivering value to the end user.
The Industry Needs to Mature
The broader tech industry has a maturity problem. Too many companies chase perfection in ways that are wasteful and demoralizing. Zero tech debt shouldn’t be your goal. Instead, aim for manageable debt, that is a state where your team can build confidently without the weight of ignored problems.
Conclusion
Next time a manager promises a “zero tech debt initiative,” smile and nod. Then gently remind them that like a unicorn, it’s not real. If they don’t accept your advice, leave.
Tech debt isn’t the enemy; pretending it doesn’t exist is.