I am sure we have all heard the term "technical debt" in our projects and teams. While generally, it is a good idea to fix technical debt, there may be times when it makes sense to carry some tech debt.

Let's start with a bit of a definition:

What Is Tech Debt?

Technical debt (or tech debt) is a metaphor that describes the cost of writing a suboptimal solution now, instead of a better solution that would take longer.

Just like financial debt, tech debt incurs "interest": over time - the shortcuts taken now can slow down future development, introduce bugs, reduce code quality, and make systems harder to change or maintain.

As the project incurs more debt, it becomes more difficult to add new features and so slows down delivery.

The term was first coined by Ward Cunningham, who explained it as the cost of future refactoring due to immature or rushed design decisions made today.

It is important to mention that not everything wrong with the system is tech debt. For example, if you are missing a key functional requirement, that isn’t tech debt but rather just a missing requirement. Also, bear in mind that the idea of what perfect code is, can vary from person to person, so because code isn’t the way you would do it doesn’t necessarily mean it is tech debt.

Types of Tech Debt

Deliberate Debt: A conscious decision to take a shortcut, usually for speed-to-market or to meet a deadline. Teams might plan to clean it up later (although "Nothing is quite as permanent as a temporary solution"). The team knows they are doing sub-optimal things, but the project will reach its goals sooner by taking this shortcut.

Accidental or Legacy Debt: Caused by evolving requirements, lack of knowledge, or outdated practices. Code that once made sense no longer fits current needs.

Bit Rot or Entropic Debt: Accumulated over time as code becomes tangled, duplicated, or undocumented due to poor maintenance or neglect.

Tooling and Infrastructure Debt: Stemming from outdated libraries, frameworks, or infrastructure choices that are no longer optimal.

Signs You're Suffering from Tech Debt 

The most obvious sign that you are suffering under a weighty tech debt load is when it takes longer and longer to implement new features. An effective way to think about the signs are if something that previously would have only taken a day now takes a week.

So, going back to the original question: When should you fix tech debt? Most people would answer ‘always!’ but there are some cases where you shouldn't bother.

When to Ignore Tech Debt:

There are higher priority items to implement or fix: Sometimes this is a painful choice for us as technical people to make but remember to always focus on the goal of the project. If, by implementing a new feature in a sub-optimal way, you can meet the goals of the project or be first to market, rather do that than spend time fixing things that won't help the project succeed. While we all want our code to be beautiful, be pragmatic in balancing the needs of the business and the project with our idea of a perfect codebase. Your clean, sexy code might not be as valuable as you think. As Neal mentioned in his article, prioritise practical and pragmatic over principled and perfect.

Prototype or MVP Stage: You are moving fast and breaking stuff. Writing the most perfect system doesn't make sense since it could be replaced next week.

Debt Is Isolated and Low-Risk: If it doesn’t impact core functionality or future work, it can often wait. Wrap it in some kind of isolation layer, put some tests around it and then just view it as a black box.

No One Touches That Code: If it is a deprecated feature that is living in the codebase and isn't likely to change in the future, just log it and move along.

Another way to look at solving tech debt is that it is an investment in future development. I like to say it is an investment in future happiness. If I clear up this debt now, it will make that future work easier and/or faster. FYI, this is another way to talk about tech debt with business stakeholders: invest some time now and get the rewards later.

Using this logic, if there isn't any future development coming, then it is better to focus your efforts elsewhere.

However, this isn't an excuse to just ignore the tech debt within your projects. We need to manage it proactively and transparently:

Managing Tech Debt Proactively 

Track It: Use issue trackers or debt registries. If you don't log it, you'll forget it. Consider things like decision logs and Architectural Decision Records to record the historic reasoning behind these "bad" pieces of code. Make sure that your project owners are aware whenever you deliberately introduce tech debt for the sake of delivery.

Prioritise It: Not all tech debt deserves the same attention. Assess impact, frequency, and risk. How much future happiness will be created if I fix this piece of code now? Look for the one that will give the maximum happiness with the least amount of effort.

Make It Part of Your Process: Allocate time in each sprint for tech debt cleanup. This will vary between teams, projects and how bad the situation is.

Measure It: Use metrics like code complexity, test coverage, or deployment frequency to get insight into growing (or shrinking?) debt. You can then show the impact of your efforts to the project owners and get them on board with your fixing journey.

Final Thoughts

Tech debt isn’t always bad—it’s a natural part of any software development project. Like financial debt, it can be a strategic decision, but unmanaged tech debt can cripple a product’s long-term growth and maintainability.

Recognising it, understanding its impact, and balancing short-term goals with long-term health are key to building sustainable, high-quality software systems. 

In short, tech debt is inevitable, but unchecked tech debt is avoidable. Know when to take it on—and when to pay it off. 

Dean de Bree - Seer of Solutions