What is Technical Debt?

Technical debt has many definitions. One of the better definitions comes from the Information and Software Technology Journal where it is described as the “consequences of software development actions that intentionally or unintentionally prioritize client value and/or project constraints such as delivery deadlines, over more technical implementation, and design considerations”.

Coined by Ward Cunningham, an author of the Agile Manifesto, technical debt has become a popular term in the software industry. It is a euphemism that describes what happens when a shortcut or workaround is opted for in software development, at the expense of clean, logical structures that are easy to support and maintain in the future, or because the nature of the software has changed sufficiently that there is now a logical structure in the code that no longer is optimal for its end purpose.

Types of Technical Debt

The wide variety of technical debt definitions gives rise to different forms in which the metaphor may be said to be exhibited. Put differently, its types typically vary from one author to the next based on the definition.

Steve McConnell, an internationally-recognized expert in software engineering and project management, identified two types in 2007. He called them intentional debt and unintentional debt. You incur one for strategic reasons while the other is simply the result of “a poor job.”

While McConnell focused on intent, Martin Fowler of ThoughtWorks added context for his own classification. He identified deliberate, inadvertent, prudent, and reckless debt in his Technical Debt Quadrant.

Setting aside the categorization of technical debt simply based on strategy or intent, some researchers later called for classification according to nature. They, therefore, identified the following 13 types in a 2014 paper:

• Architecture 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

Apart from the foregoing, there are other classifications based on different considerations. Outside of the technical realm, it is important to realize Product Debt (aka experience debt) can also be incurred for similar reasons, when the needs of customers become neglected and the product becomes more difficult to use and detached from their fundamental needs.

Should Technical Debt be Avoided?

Debt is something most people would love to avoid if they can, but it is inevitable in many cases.

The story isn’t that different with technical debt. We can’t categorically say it is bad and should be avoided firmly. Problems only start when you fail to pay back as due.

In the software industry, the choice is usually between releasing features quickly and taking the time to ensure the best quality. Most companies opt for the former option in most cases. Startups in particular feel a greater pressure to release something quickly, even though it creates technical debt.

Perspectives on whether this debt is good or bad are greatly influenced by the methodology in use. Agile companies mostly don’t see it as being bad since the aim is usually to ship and iterate. For companies using Waterfall methodology, on the other hand, technical debt is typically best avoided.

Taking a “technical loan” isn’t bad if it is justifiable strategically. In this case, you decide on it because you understood the costs and benefits very well. It can, for instance, let you have something in the market that you can look to improve on in future releases.

How to Pay Back Technical Debt

While it might seem that taking the time to improve quality implies greater costs, it can actually reduce them. Placing greater importance on quality can help prevent a buildup of quality deficiencies that make modifications and further extension of software systems more difficult.

In his article on technical debt, Fowler compared the extra effort needed to fix deficiencies, or “cruft,” and add new features to an interest payment on a debt. What is the right approach to paying back your technical debt, if you have incurred any, to reduce the possible negative impact?

Have all hands on deck

Paying back a technical debt should be a collaborative thing. Everyone on the team should play a part in correcting deficiencies in software systems. Reworking defective code should ideally not be made the purview of only a few to keep things from becoming more complicated.

Start quickly

It helps to not allow cruft to build up too much before you start tackling it. This will be beneficial for ensuring that the costs of improving software quality down the line don’t prove too high. You should start reworking the code as soon as possible. This can go a long way in keeping your customers or users satisfied.

Do it gradually

Reworking code is a less-exciting thing to do; it’s more appealing working on new stuff. Here’s another reason cruft shouldn’t be allowed to build up too much before you start paying back the debt.

You don’t have to correct everything at once. It may be better to take things bit by bit and be consistent about it. Agile teams can, for instance, create some time in individual sprints for correcting deficiencies.