<Technical Debt: What It Is And How It Helps?/>

What Is Technical Debt?

The concept of technical debt can be best understood in comparison to financial debt. You may take on financial debt for a specific reason, such as a mortgage for buying a home or a personal loan to meet a major expense. But that debt has to be paid back, on time, or there would be trouble. Similarly, you may take on technical debt or code debt for a specific reason. Usually, that reason is to meet a deadline for finishing a code or delivering a piece of functionality. The debt (whatever its nature may be) needs to be paid back, i.e., refactored in the code for proper completion or reworking the piece of functionality to make it optimal/perfect.

In most cases, technical debt is a debt of time. You save time on one phase of the development by bypassing the due process and writing code that’s functional but incomplete, unrefined, or dirty. But you need to make up for that time and pay back your technical debt by reworking the code at a later date or work on it in bits and pieces (like paying off your mortgage debt). And like financial debt, you may have to pay interest on your debt. That is spending more time than you originally would have in the first development phase in reworking the code.

Code debt is the most common type of technical debt, and it’s just one segment of a much broader spectrum. But almost all technical debt follows the same premise, i.e., you prioritize fast delivery over the perfect finished product, and you have to come back to it, later on, to pay back your debt (like a Lannister).

What Technical Debt is NOT

There is a consensus (sort of) among agile developers about what technical debt is (anything that has to be factored in or reworked later on) and the consequences of not paying off your technical debt (bad code, impossible to modify/scale functionality, angry clients, etc.).

But what technical debt “isn’t” is still debatable. Some developers believe that writing messy code to save time is not taking on technical debt. Others disagree. Some believe bad code is akin to unintentionally incurring technical debt, which has to be fixed later. In contrast, others associate it only with intentional and strategic decisions related to expediting delivery. The main reason for these conflicting opinions is two different schools of thought in agile developers. One believes that technical debt is a tool (which infers intentional usage) while others consider it a negative consequence of rushed delivery.

Classification of Technical Debt

Over the years, technical debt has been classified in a number of different ways. In 2007, one classification divided technical debt into two categories: Intentional debt (a strategic decision) and unintentional debt (mistakes/poor code).

It was further expanded into a full quadrant by Martin Fowler in 2014, who combined intent with context. (Source According to the quadrant, the worst technical debt would be unintentional and reckless. And the best would be intentional (deliberate) and prudent. If we draw a financial analogy, the worst technical debt would be racking up your credit card bill and taking out cash advances without understanding the consequences. The payback might be significantly more cost (time) intensive, more resource-draining, and purely a liability. On the other hand, an intentional and prudent debt will be like finding the best mortgage rate and paying it back on time, which will result in an asset.

Another way to classify technical debt is by its nature, which results in 13 types of debt:

1. Code
2. Build
3. Design
4. Architecture
5. Infrastructure
6. Defect
7. Documentation
8. Process
9. Service
10. Requirement
11. Test
12. People
13. Test Automation

Should You Consider Taking On Technical Debt?

Even if you are not ready to intentionally and strategically leverage technical debt to make your delivery process more efficient (and quick), you may already have technical debt, or you take some on unintentionally. So the first thing you need to focus on is paying your technical debt. You should make a schedule and devise a protocol about how to pay off your technical debt. Think again in financial terms. If you spend your paycheck on paying off your financial debt, how will you meet your necessities?

Similarly, if you spend your precious time and resources on reworking previous code and completing older documentation, how will you find time to pursue your current projects? Some good practices are:

• Create a plan, a time budget for paying off your financial debt.
• Don’t delay reworking poor code. The longer you wait, the more users might get accustomed to the wrong code, and major changes, even positive ones, might impact the experience.
• Like agile development, reworking and refactoring in iterations might be more productive and efficient than repaying all your debt at once.
• Don’t delegate paying off technical debt to one segment of the team. Everyone involved in the original development should also be part of the rework.

When you have a protocol for paying your technical debt in place, you might consider taking on technical debt deliberately and strategically. It might prevent you from missing deadlines even if you are short-staffed or let you run more projects in parallel, which might be beneficial for cash flow.

Pros and Cons of Technical Debt

If you consider the broad definition of technical debt, which accounts for unintentionally incurred technical debt, it's a natural consequence. If you stick with the intentional definition, then it's a tool that is neither inherently good nor bad. If used the right way, you can leverage the strengths of technical debt, allowing you to meet your immediate needs while spreading out the “repercussions” over a longer period of time.

And if you fail to pay off your technical debt, it might overwhelm your resources and raise questions regarding your ability to deliver high-quality work on time. It’s important to note that agile developers are more open to leveraging technical debt, while software or app development teams that follow the traditional waterfall methodology are not.

Conclusion

A good DevOps team, an in-house or outsourced software team, understands the value of knowing all their options. Technical debt is one of the options. But even if you don’t use it intentionally, understanding that it exists and how to pay it off should be a point of focus for every development team.