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.
The most common impact is development 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.
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.
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 rate, deployment frequency
- Immediate suspects — build process, big classes, buggy modules
- Slowness — in your delivery; “why is everything taking so long?”
- Error increase — a trend of an increasing number of errors or incidents
- Frustrated engineers or 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 I 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.