Tech Debt: A Thorough Explanation and Guide to Fixing It

Plutora BlogAgile Release Management, DevOps, Software Development, Value Stream Management Reading time 15 minutes

Technical debt is an incredibly useful metaphor in software engineering. It can encourage meaningful conversations about the trade-offs and hard choices that are part of the daily routine of software development teams and organizations. Those conversations can then lead organizations to make smarter decisions on how to allocate their resources and prioritize their various activities. Unfortunately, due to misconceptions and conflicting definitions, the term “technical debt” has become quite loaded. Different people might mean diametrically different things when they say “tech debt,” which reduces the usefulness of the term as a conversation starter. For instance, there are people who equate technical debt with “bad code.” As you’ll see today, the real meaning of the term is deeper than that.

So, in today’s post, we take upon ourselves the mission of correcting this problem and returning “tech debt” to its deserved place as a useful software engineering metaphor. We’ll start with some fundamentals, defining tech debt the correct way and giving a quick overview of the origins of this phrase. You’ll see examples of what technical debt is and isn’t, and you’ll learn whether or not technical debt is always bad.

Then, we’ll provide a guide on how to fix tech debt. We’ll explore the causes of technical debt and the consequences of leaving it unchecked, and conclude with the approaches you can use to get rid of it.

Quality software releases at scale with Plutora

Let’s get to it.

Tech Debt 101

A Simple Definition

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

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

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

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

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?

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

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?

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

Unexpected Project or Endeavor

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

Poor Communication With Customers

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?

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

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

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)

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 new knowledge you gained since you first designed.

Tech Debt: A Software Organization Frenemy

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!

Interested in more value stream management features to boost your software delivery process? Check out more great articles on our blog:

Learn how to improve the speed, quality, and visibility of your software delivery.