Understanding Tech Debt

Anyone that has been in the software development circle for some time has probably come across mentions of the term “tech debt” or involved in discussions on it.   But is tech debt good or bad? While this expression inherently characterizes is as something negative, the truth is there are times and reasons when incurrent a little tech debt can be a good thing. And often finding that balance is the key to optimal outcomes.  This article aims to go deeper on this topic. 

What is Tech Debt?

This term often used in the software industry traces its roots to the financial world. It practically entails what the regular debt is – something we opt for to enable us to achieve a target now. Once we take it, we have to pay it back. Technical debt, also called design or code debt, is open to different interpretations as metaphors like it often are. The term was invented by Ward Cunningham, one of the Agile Manifesto authors, to describe what happens when development teams prioritize shipping something over writing clean code. It is rushing to build something while leaving aspects that would still need to be properly sorted later.

According to Cunningham, technical debt is like borrowed money. It enables us to do something sooner. However, until we pay back that debt, we will continue to pay interest. When it comes to the software industry, this interest could mean ending up with code that is more difficult to maintain.

The definition offered in an article in the journal Information and Software Technology probably best captures what technical debt is. According to the authors, it is “the consequences of software development actions that intentionally and unintentionally prioritize client value and/or project constraints such as delivery deadlines, over more technical implementation, and design considerations.”

Types of Technical Debt

Technical debt varies. Different authors have come up with diverse types of this phenomenon. Going back to the definition given above, we can easily make out two types:

• Intentional technical debt
• Unintentional technical debt

These are similar to what some authors call deliberate technical debt and inadvertent technical debt.

Intentional technical debt

As the name suggests, we incur this sort of debt fully aware of what we are doing. It is what results when we have to choose between the right way and the fast way. The right way can be swift as well but not always.

Sometimes, the team may be under pressure to ship something quickly. This might make developers rush to build a product to push to the market even if the code written isn’t perfect. The technical debt thus incurred is deliberate to make it possible to ship something.

Unintentional technical debt

One thing that somewhat distinguishes technical debt from financial debt is that it may also be accidental. It is hardly possible to borrow money by mistake. In software development, however, we can incur technical debt without fully setting out to do so.

Inadvertent technical debt is simply nothing more than a slapdash job. It is producing poor code or bad design that is beset with a variety of issues down the line. It’s what occurs when we fail to exercise our due diligence while developing a design or functionality. Unintentional technical debt leaves us with more work to do fixing what has been done at a later time.

In the book The Smarter Startup for example, there is a chapter titled “When Code Should Suck” that addresses this very point.  The point is that intentional debt can actually be a strategic tool, especially in early-stage company that can expect to pivot early and often.  The argument here is that it would tremendously slow down finding product-market fit if the team were to take time to refactor the code in a perfect way, with every pivot.  Instead the author argues, let the initial version of the software intentionally be a mess, with the expectation you’ll do a clean re-write, once the company has found fit, and is ready to begin scaling.

Some academics have, however, faulted the idea of simply classifying technical debt as intentional and unintentional. They called for the description of debt according to their particular nature. As a result, they came up with 13 separate types, namely:

• Architectural debt
• Build debt
• Code debt
• Defect debt
• Design debt
• Documentation debt
• Infrastructure debt
• People debt
• Process debt
• Requirement debt
• Service debt
• Test automation debt
• Test debt

Technical Debt Can be a Useful Tool

Incurring technical debt isn’t necessarily a bad thing. It is a tool that we could put to good use, especially in Agile. It may only be considered outright bad in Waterfall companies, or when it reaches a point of excess that is impeding progress on other things. The software industry is highly competitive. Teams are constantly under pressure to build and ship fast. There is also the “First Mover Advantage,” which could make it especially irresistible to push something to market quickly.

We know that we may not have our best code yet but we are willing to take the risk. It’s either we do that or wait until a later time before shipping. The nature of Agile especially makes technical debt not to be intrinsically bad. Things are done in iterations. We don’t get to work thinking we’ll build the perfect product at the first shot. Rather, we ship, learn, and use our learning to improve the next iteration.

However, technical debt is what it is. They enable us to do something faster or accomplish more today. But we must repay the cost at a later time for us to have better code. The debt will require a higher cost or more work to fix at a later time. We shouldn’t let our technical debt pile too high before we start addressing them. We should endeavor to set aside time and resources to refactor the system from time to time. It will also help to keep a list of the debt to pay for easy tracking.