The Effects of Technical Debt

Oleg Geranin (for Finiata)

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.

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.

Oleg Geranin (for Finiata)

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.




Happily programming since 1984

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Argo Events v1.0 Released!

Remote Work: Blowing Off Steam

How we built a 10K email list for our online course

Security On Azure

BSides San Francisco — Recipes(204 points)

OCI DevOps-Free Automated Cloud Native Application Deployment to Oracle Cloud

How We Secured Our AWS S3 URLs — Strategy & Implementation

What Is RESTful API? How to Create and Use RESTful APIs?

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Yaniv Preiss

Yaniv Preiss

Happily programming since 1984

More from Medium

Managing the software development team

Own your technical debt

Fixing (software) estimation issues using first principles

My Three Principles of Product Development