by Suzanne Erin on May 16, 2019

One of the biggest challenges around technical debt in software development is how to communicate its true costs to stakeholders and decision-makers. The first part of this two-part series on technical debt explores some ways it can be helpful to think of technical debt like financial debt.

Technical debt is a term to describe the shortcomings of existing code that could be changed to perform better, and the ongoing consequences for failing to address it.

There are two ways to generate technical debt: actively and passively.

Technical debt is incurred actively when development has taken a shortcut. Maybe it was a hack solution or skipped a step to build a feature faster, but now the code is hard to extend or unsuitable for long-term performance. Sometimes, a shortcut is a conscious choice to get something done sooner. Other times it’s an unanticipated consequence of not having enough time or resources to think through more elegant long-term solutions. Either way, eventually it becomes a noticeable source of friction.

Technical debt also grows passively with the passage of time. You may have written perfect code when you started -- but the ecosystem that the software lives in is changing. The version of the language you are using may become out of date. Dependencies, chunks of open-source code that are incorporated into your codebase, may become unsupported or develop vulnerabilities. Browsers develop new requirements. You need to maintain this code in order for it to keep working as intended.

The thing that I love about the term technical debt is that its name gets right to the heart of why it is important. Technical debt operates similar to financial debt. The two definitional aspects of debt are salient here:

1. You have to pay it someday.
2. It accrues interest. The longer you wait to pay it, the more it will cost to get rid of it.

These two points are true of technical debt too. In software, development time is literally money. The parallel is less an analogy and more a literal truth:

1. You’ll have to spend time fixing it some day.
2. Time makes it harder to address. The longer you wait to fix it, the more it will cost you.

Making the choice to get into technical debt in order to get a feature out faster is like paying with a credit card. It is a more convenient method to pay for something right away. It might be a valid decision in the moment. But, you will pay interest on that purchase over the long term. It isn’t wise to make a habit of putting everything on your credit card without knowing how or when you’ll be able to pay it off.

On the other hand, technical debt that accrues naturally over time is a little like owning a home. You have to decide whether to keep up with maintenance or defer it. If there’s a small intermittent leak under the sink, you might be able to get away with sticking a bucket under it. But, if left unaddressed, small leaks can turn into big expensive problems. Your home’s value depends on how well you keep it up.

Technical debt in your software has real costs in terms of time. Like compounding interest, they aren’t one-time costs, but continue to build on each other. It continues to slow you down. There are three main ways that technical debt accrues this interest:

• It can generate more issues
• It slows down new feature development
• It gets harder to fix

Technical debt will generate issues if your code is no longer working well for you. If you put off improving underlying code, users will be more likely to report problems that you will need to spend time fixing.. Eventually, the time you’ve spent putting band-aids on issues will outweigh the amount of time it would have taken to fix the underlying problem.

Technical debt slows new feature development. It is code that is hard to work with. It might have patterns that are tedious to replicate, or it might require long work-arounds every time you want to add something new. It might require creating or looking up documentation that becomes increasingly harder to find. It will continue to slow development down more and more.

Technical debt gets harder to fix the longer you ignore it. As you grow the software, the troublesome pattern is being extended and integrated into a larger and more complex codebase. There will be more of it and it will be touching more things. The longer you wait, the harder it will be to change.

In each of the above cases, we can see technical debt has real compounding costs in terms of lost time. Time is money, so ignoring these issues for too long is like failing to pay a credit card, or failing to budget for maintenance on your home.

Dealing with debt involves making a budget. The second part of this series explores strategies to help manage your technical debt load.

Image by: jonathan Ford