The Effects of Technical Debt

The definition of “technical debt” is similar to financial debt – borrowing resources from the future in favor of what is needed in the now. The goal is to achieve something in the short term, knowing that it will have to be paid back at a later date, with interest.

Implementing a feature “quick and dirty”, to determine if it’s worth keeping – and then later cleaning up the code, is one of the most common ways technical debt is created. How the different types of technical debt impact your product, company or feature will likely vary. 

In some cases, creating some technical debt can be a good thing. But if it isn’t paid back, things can become very problematic.

The negative impacts of technical debt

Deliberately or not, some types of technical debt can negatively impact organizations. We’ve provided some examples of the most common negative effects. 

Slowness

The most common impact is slowness – teams find it hard to make changes to existing features, delete features, and introduce new features. Something that took one engineer a single week to finish before, might take two engineers 3 weeks now.

Fear of working on certain code

Besides necessary unplanned work, there can be a fear of touching certain areas of the code and a high cognitive load. As well as the need to consult others and double-check before making changes.

Inability to deliver

Another major potential effect is the inability to deliver a key feature, as the current implementation does not support an easy change or requires a profound re-architecture.

Unwanted surprises

As a result of the relatively poor state of the code, there are often minor and major incidents, such as bugs being found just before the release date, or developers announcing that they cannot implement something until the debt is paid. Other surprises might be due to the end-of-life of an old library or an urgent security vulnerability.

A slew of errors

The higher the debt, the more likely it is to find errors in the code – we’re talking about bugs. If code isn’t clean, it increases the chances of there being far more bugs in the code that can greatly impact the final product and how it functions. 

Voluntary attrition

Engineers might get demotivated over time and fed up with the poor state of the codebase and decide to leave the organization. This usually means they’ll have left to find out that other companies have technical debt as well, but they will likely look for greener pastures.

Feeling like a “feature factory”

Another cause might be the feeling of a “feature factory”, where engineers are just the execution arm, a.k.a “code monkeys”, and never get to work on technically interesting things. This reduces employee satisfaction greatly. 

How to identify technical debt

There are a variety of ways you can identify your organization’s technical debt. The following are some helpful conditions to look out for to determine how much technical debt you have and where it lies. 

• Metrics – lead time, faulty deployments, deployment rates
• Immediate suspects – build process, big classes, buggy modules
• Slowness – in your delivery
• Error increase – A trend of an increasing number of errors or incidents
• Frustrated engineers/product managers – direct or passive-aggressive complaints, asking engineers directly, or conducting regular surveys
• Fear of working on code – The fear of touching certain areas of the code

Learning to manage your technical debt

Understanding what technical debt is, and how to identify it are only the first steps. Now it’s time to start paying back that debt – but how? One book we’d recommend checking out is “Your code as a crime scene.” It’s full of interesting observations about locating and handling problematic areas of your code.

You must examine how to deal with your technical debt so that you can start paying it back, and reduce the number of negative impacts it is having on your organization.