Tech Debt: A Thorough Explanation and Guide to Fixing It

Tech Debt 101

We'll start with some fundamentals on tech debt, so we're all on the same page regarding the meaning of the metaphor. 

A Simple Definition

Let's start by answering the most obvious question: what exactly is tech debt? 

This is what Wikipedia has to say about the concept: 

Technical debt (also known as design debt or code debt, but can be also related to other technical endeavors) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.

Basically, technical debt refers to a common situation when designing software: purposely choosing the fast solution, based on your current understanding of the problem, instead of waiting until your understanding matures and you reach what would be the correct solution. While the latter solution is better in the long term, the former is faster and easier to implement. However, picking the easier and faster solution isn't free: it brings you consequences down the road, in the form of rework and an overall difficulty in making necessary changes to the project. This extra effort is akin to interest you pay when incurring a real, financial debt. 

It's very easy to misunderstand what technical debt means. If, from the definitions above, you've got the idea that technical debt means doing the wrong thing on purpose to buy time and then fix it later...well, you're not alone in that. But that's not the correct meaning. 

Throughout this post, we'll debunk some common misconceptions about tech debt. Before we get there, though, let's have a quick history lesson. Where does this term come from? And how long has it been in use? 

Time for History

The term "technical debt" was coined by Ward Cunningham. He came up with the metaphor as an intuitive way to talk about software complexity that accumulates over time, creating the necessity for additional work, making it harder and harder for engineers to continue evolving an application. 

Sources seem to agree that Ward Cunningham first mentioned it in a report for the 1992 OOPSLA conference. 

What Is Not Technical Debt? Common Misconceptions About the Debt Metaphor

As we've mentioned, the current usefulness of the tech debt metaphor is reduced thanks to the myriad of misconceptions floating around the term. In this section, we'll review and debunk some of the most common and persisting myths related to technical debt. 

For instance, many people seem to believe that technical debt is synonymous with having defects in the code. Another common view is that technical debt refers to writing bad code with the intention of fixing it later. 

To be fair, the statements above have at least a kernel of truth. The correct definition is more subtle, though, as you'll soon see. 

Tech Debt != Bugs

There are people who use the term "technical debt" as if it was the same as defects or bugs in the code. That's a common view, but it's wrong. As you'll see repeatedly throughout this post, incurring technical debt is a conscious choice. Acquiring tech debt is a trade-off you make, with the intention of speeding up the development and release of whatever software you're working on. 

Introducing bugs to a codebase is an intrinsic part of the software development profession, but it's accidental. (Well, at least I hope you're not writing buggy code by design!) 

Acquiring tech debt, on the other hand, is intentional. It's a tool you might use to enable the release of an application in a timely manner. 

Tech Debt != Writing Code Poorly To Fix It Later

Have you ever written code that you knew was bad with the intention of getting back and improving it later? I know I have, and I bet you have as well. Now, a second question: did you manage to go back and improve the code later? If I had to bet again, I'd say you didn't. I plead guilty of that myself, your honor. 

That's a situation that many people call tech debt. This view is both more sophisticated and closer to the correct meaning of the technical debt metaphor than the last one. It's still wrong, though. 

That's right. Technical debt does not mean writing bad code with the intention of fixing it later. Don't believe me? Here's a quote from the metaphor's creator himself: 

I’m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial.

So, what is tech debt after all? 

Technical debt is about consciously choosing to speed up software development by going with a design that you know is likely not quite right, due to your current incomplete understanding of the problem. (Sometimes this is defined as a more specific form of technical debt, design debt.) 

Deferring tasks that aren't crucial to getting the software out the door but will eventually be needed can also be considered technical debt. 

Is Technical Debt Bad?

As Ward Cunningham himself puts it, technical debt is a way of "rushing software out the door." Incurring technical debt is a conscious choice you make with the intention of speeding up development. So...is it bad? To answer this question, we have to turn our focus to the origin of the metaphor: financial debt. Is financial debt bad? 

Well, it depends. Let's say you need a reasonably large amount of money to invest in your business idea. You could save a portion of your income to amass the whole amount, but that would take you years. Alternatively, you can get a loan. Yes, you'll pay interest, and I'm pretty sure you don't like interest (unless you're the lender, that is.) but the possibility of being able to get that money is a good thing. It enables you to start your business right now instead of in five or ten years. 

However, the benefits quickly disappear if you fail to pay the debt back. Due to the awesome and terrifying power of compound interest—which Einstein may or may not have called "the eighth wonder of the world"—the amount you owe can get shockingly high. 

After the example above, it should be clear that financial debt isn't intrinsically bad. If you use it responsibly, it's a tool to allow you to reach some accomplishment faster than would've been possible otherwise. On the other hand, if you don't use responsibly, the accumulated interest will come to bite you sooner or later. 

Fixing Tech Debt

It's now time to get to the part of the post that many of you were waiting for: the guide on how to fix technical debt. However, you might be wondering: is there really anything to fix about tech debt? After all, we've spent a good portion of the post arguing that tech debt is a conscious choice, rather than an accidental problem, and that's not intrinsically bad. 

So, let's clear this up: from this point on, when we say "fixing tech debt," that's a shortcut for "fixing tech debt gone bad," or "fixing unpaid tech debt." With that out of the way, let's move on. We'll first explore the causes of tech debt accumulation. Then, we'll quickly cover the nastier consequences of tech debt left unchecked. Finally, we'll walk you through a list of practical steps you can use to get rid of your unpaid tech debt—or prevent it from accumulating in the first place. 

What Causes Technical Debt?

What are the causes of tech debt accumulation? To answer that, just think of financial debt and the reasons why people accumulate it. Someone might suddenly become unable to pay their loan back due to losing their job. Maybe getting the loan wasn't such a good idea in the first place, since it put their domestic budget under too much stress. They could already have another loan they were paying back, and they should've waited until that loan was finished before taking on another one. Also, don't forget that life plays tricks all the time: maybe something like a broken car or an unexpected illness jeopardized the person's ability to pay the loan. 

There are many possible reasons that can harm someone's ability to pay their debts. Let's now see how those situations might map to our tech debt metaphor. 

Understaffed Team

You pay financial debt with money. Tech debt, on the other hand, is paid with person-hours of development work. So, a situation analogous with a person losing their job could be a software team suddenly finding itself a few developers short. Having an understaffed team can seriously harm the capacity of an organization to pay back its debt tech. When pressured for time, most managers would surely have their team prioritize adding new features or correcting bugs in the application rather than refactor what already works. 

Unexpected Project or Endeavor

In the same way that unexpected life issues can reduce the amount of money a person has available to meet their debts, a similar situation can occur in an organization. Priorities change all the time. A development team might need to quickly change gears in order to meet a new commitment made by the sales department. Or maybe a few incredibly severe defects were found in a project, which required several developers to handle. 

In other words: an unexpected situation might make a company temporarily understaffed. 

Poor Communication With Customers

Sometimes, people might take on more debt than is wise. Organizations can do the same, incurring in unjustified technical debt. 

As we've already seen, technical debt occurs when a software team chooses to ship code using a partial understanding of the problem they already have rather than waiting until they have a more complete picture. The problem is that, often, they could've achieved a better, more comprehensive view of the problem had they communicated better with their customers. 

In other words, poor communication with your client can lead to an unjustified partial understanding of the problem. That causes you to take on more tech debt than you should. 

What Happens When Technical Debt Increases?

What are the consequences of technical debt left unpaid? It makes further changes to the codebase harder. That is, you pay interest when performing those changes. 

Let's say you have a group of classes that are more complex than needed. You couldn't help but code them that way the first time around: you made a conscious choice to go with the imperfect understanding you had. That's fine. 

But if you never go back and use the knowledge you gained since then to improve the design of the classes, that's going to harm you. When it comes time to add new features to those classes, it'll be more difficult than it could've been. Instead of taking you a few hours, it could take you two or three days. 

Now, keep in mind that, in real life, you won't have just a single instance of tech debt. You're likely to have a lot more, depending on the type of software you make. A relatively simple mobile app could have any number of technical debts, from a few to a few dozen. If we're talking about enterprise software, however, this number could easily surpass the hundreds. 

So, take the example of increased time to deliver a feature and think of how many instances of technical debt a large enterprise software application could have over its lifetime. It becomes clear that technical debt left unchecked can lead to an astonishing number of development hours wasted. 

How Do I Get Rid of Technical Debt?

How do you get rid of accumulated technical debt? Mainly in two ways: you either repay it constantly, or you avoid acquiring it in the first place. 

Improve Communication and the Flow of Information

As we've seen, one of the reasons technical debt accumulates is that organizations often incur debt when they don't really need to. Due to poor communication, they fail to understand the problems and needs of the client, developing an unjustified incomplete view of the problem. 

Often the requirements were correctly gathered, but for some reason, the organization failed to reach the professionals when they were making design decisions. To prevent this situation, make communication efficient, with a faster and more accessible flow of information. 

Value stream management can come in handy here. By enabling organizations to create single sources of truth and open communication channels, VSM can help them ensure the right information is available at the right time for those who need it, mitigating the risk of developers incurring unnecessary technical debt. 

Document Every Time You Incur Debt

As we've discussed at length, tech debt isn't always bad. It's a tool, and sometimes acquiring a bit of debt is the push your company needs to get to market in time. What you can't forget is that you need to pay that debt down, and often. But how are you supposed to do that if you can't remember how many times you incurred technical debt, when you incurred it, and under what circumstances? 

It's essential for an organization to easily be able to track down their past debts. The organization needs to be able not only to see details related to the tech debt occurrence, such as description and date. It's also crucial that it can sort those occurrences based on severity and other criteria. This capability will help the organization prioritize its debts in an efficient matter when it's time to repay them. 

ABR (Always Be Repaying)

If you want to prevent tech debt from accumulating, you need to pay it back, constantly. So, the previous point is a necessity for the current one: there's no way to get rid of your debt if you can't track it. 

And how do you pay back tech debt? By refactoring it. 

Refactoring, besides being the title of a famous book by Martin Fowler, is the process by which you improve a piece of code without changing how it works. After a successful refactoring session, nothing would have changed from the user's point of view. Internally, however, you would've changed the way the code is structured to match the new knowledge you gained since you first designed it. 

Tech Debt: A Software Organization Frenemy

Is technical debt good or bad? It can be both. When used wisely, acquiring tech debt is akin to getting a loan to invest in your business, or to buy a house. It's a tool to help you reach your goal, faster. However, not all people use financial debt wisely, do they? The same also happens with technical debt, unfortunately. 

Today's post was all about tech debt. You've learned a bit about the origins of the term, and how its real meaning goes way beyond than being a mere synonym to "bad code." 

Where should you go now? Having read about the practical measures you can take to prevent tech debt accumulation, a logical next step would be to learn about tools you can leverage to help you implement said measures. For instance, Plutora is a value stream management platform that helps organizations make their software development and delivery processes more efficient. Organizations that can deliver software faster due to a more efficient pipeline and infrastructure will naturally need to incur technical debt less often in order to speed things up. 

Thanks for reading, and remember: when you're in a hole, stop digging. That applies to many things in life, including being in debt—financial, technical, or otherwise. Until next time!