What is technical debt?

But first, what exactly is technical debt?

Technical debt occurs when the team decides to prioritize quick delivery over perfect code, choosing shortcuts on purpose and accepting the need for future refactoring or improvements as a trade-off.

But that case scenario, described by a software developer Ward Cunningham, refers to a situation where the technical debt becomes a conscious decision, with full awareness of its consequences. But technical debt can also catch people unaware.

For example:

• As a project goes on and people working on it leave, taking their knowledge with them, new developers might not know shortcuts were taken in the past,
• Deprecated frameworks or libraries, ecosystem upgrades, or changes in infrastructure might lead to obsolete code that has to be refactored,
• As more and more features get added, resulting in a ‘feature creep’, both the product and the code can get uneccesarily complicated,
• New industry standards may also require changes to previously acceptable code.

Why is technical debt sometimes necessary?

The aforementioned Ward Cunningham has brilliantly compared the technical debt to a financial one, saying:

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring. The danger occurs when the debt is not repaid. Every minute spent on code that is not quite right for the programming task of the moment counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unfactored implementation, object-oriented or otherwise.”

Even though that citation goes back to 1992, the sentiment still rings true. During Future Mind’s webinar on effective mobile development, Michał Kubik, Head of Engineering at AirHelp, references that analogy:

“If we want to have an apartment, we need to take on debt, right? In the case of software, to meet business expectations efficiently and quickly, we have to take on debt. We often take shortcuts. We don't start by thinking everything through and building super-optimized systems that won’t have technical debt, because that simply takes too long, it's costly, and the business side won't agree to it. So we just have to take on that debt, but we need to monitor it”.

When technical debt is part of the plan, it can significantly cut on time and costs involved. But what happens when the technical debt surprises the team?

The dark side of technical debt

First of all, technical debt can slow down the development process. Upon discovering issues from the past, the team has to switch gears to find their source and come up with a solution. In the case of more complex problems, the process can take up to several iterations, especially if there’s no documentation.

One of the metrics of the tech debt is ‘code coupling’ which tells us how much different parts are interconnected – can we touch a brick in this part without worrying that a tower will fall apart somewhere else? The more interconnected the code is – meaning one part can influence another – the harder it gets to fix bugs and add new functionalities. Everyone is afraid to touch such a fragile structure.

Last but not least, the team's morale is also an important aspect to consider. With no refactoring plan in sight and working on unstable code can quickly lead to mounting frustration.

How to manage technical debt?

In the case of intentional debt, it’s of utmost importance to track and document it. It may seem redundant with small changes that stand out from the rest of the code, but if there are overlaying layers in the structure, any issues might not be visible at first; developers would have to go layer by layer to uncover the full scope of the tech debt. This, in turn, makes it difficult to assess the risk and costs of refactoring. By documenting it from the get-go, the team will avoid any nasty surprises.

Next, a plan for refactoring needs to be set in place. When will the team pay off the technical debt and how? Will it happen immediately after each new feature the debt was taken on is released, or only after several have shipped? Will they choose a specific day of the week to focus on it, or will they stop everything else for a while?

After deciding on how to implement refactoring into the roadmap, it’s crucial to emphasize its importance to the business team. Often enough, engineering and business teams are at odds with each other, sharing the same goals – success of a product – but lacking the necessary understanding to see the full picture. If both sides are aware of the dangers of the mounting technical debt, it’s easier to communicate why another feature must wait its turn until part of the debt has been paid off.

Once everyone is fully onboard, clear accountability should keep pushing the refactoring forward. By making it a visible, shared responsibility, creating comprehensive documentation, and prioritizing the tasks, teams can manage risk proactively and maintain a healthier, more scalable codebase.

And in the future, to avoid as much of the technical debt as possible, automated testing can be implemented. Being much more efficient than manual testing, it gives developers the confidence to move on without worrying about breaking stuff (aka regression). This becomes especially important when the team is still actively working on a product that’s already live, helping ensure users continue to have a smooth, bug-free experience.

When to start paying off technical debt?

While ‘as soon as possible’ is the best answer, it’s at the same time the least satisfying one. But what’s more important is to carve out space in the roadmap for refectoring – otherwise, it may be kept pushed back or forgotten about entirely. If that’s still not possible for one reason or another, at least stay on the lookout for these warning signs:

1. When technical debt slows down delivery: if features are taking longer to build because the code is difficult to understand, inconsistent, or plain messy, it’s time. Slowed velocity is often the first sign that the debt, intentional or not, has outstayed its welcome.
2. When codebase starts to lag behind industry standards: If technical debt is preventing progress, from the inability to upgrade a library to integrate a new service or deploy efficiently, then it should take priority.
3. When bugs keep reappearing: frequent regressions or production issues in a specific area frequently point to hidden debt, especially when small changes break code elsewhere; dealing with it ensures a much more stable codebase.
4. Before major changes: adding big features, scaling up, or changing architecture can turn into an expensive nightmare if the product’s foundation is shaky and unstable.
5. When onboarding becomes painful: if new team members struggle to understand or safely work with a codebase, that’s a big red flag. Cleaning up now improves long-term productivity and team morale.

Last words

Technical debt can be a silent killer of any business. Ignoring and delegating it to ‘somewhere in the future’ only compounds the problem, with the potential to halt any progress entirely until it’s dealt with.

Teams that assume technical debt won’t touch them are unrealistic at best – in most cases, it’s an unavoidable part of development. It should be kept in mind from the get-go, and a solid plan on pay off that debt should follow.

Technical debt isn’t only a development concern. Its importance should also be understood by management and the business side, prioritizing the maintenance of healthy code across the whole organization, leading to increased efficiency and much faster development in the future.