What is technical debt?

There are two approaches to classifying technical debt: by intent or nature. Intent includes three categories: intentional, unintentional, and unavoidable. Nature currently includes 13 categories of classification. Proper identification of technical debt can help a company make strategic decisions on properly managing its debt.

• Planned technical debt. An informed decision is made to accept the risks and costs of releasing a product early and the decision-makers understand the compromises involved.
• Unintentional technical debt. A company hasn't developed an effective workflow or considered the risks of tech debt, resulting in poor communication between developers and other team members. Their developers may also be inexperienced in new coding techniques.

The 13 categories for classifying tech debt by nature include:

• 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

Debt in these areas can also be intentional or unintentional, and this approach helps companies identify where debt will or could occur and where to focus resources for reducing it.

Generally, four factors lead to tech debt: time constraints, market changes, outdated technology, and a lack of proper risk management. When a company sacrifices quality to meet a release's deadline, it creates tech debt. Companies adopt solutions to meet these developments as markets and technology change and update code to include new libraries and infrastructure.

• Time pressure. Developers often face pressure to deliver a product on time. This might lead to deploying apps that are not fully featured or contain bugs. Development teams may sacrifice an app's performance to get to market as quickly as possible.
• Market change. Even if a team releases a fully featured app, it might face changes in customer expectations. Later, it may encounter new market opportunities that prove challenging.
• Outdated technology. Several coding languages, developer frameworks, and libraries are needed to develop an application, and they become obsolete over time.
• Lack of risk management: If a team decides to implement a feature within a certain amount of time but doesn't consider what risks are involved, such as not running 100% of the necessary texts, then they can start to cut more corners.

As a natural part of developing code, tech debt can be managed properly so that it won't cause harm to a business. If not managed, tech debt can cause problems such as extended page loading times, lagging apps, and product downtime.

Tech debt is almost always unavoidable when there's a compromise between speed, cost, and quality. However, it can be a symptom of deeper problems within a company, such as poor engineering practices or efficient workflows. Like financial debt, the mere presence of tech debt isn't bad, but a company needs to avoid letting its debt grow out of control and stifle growth.

For example, a team releases a feature knowing that they took some risks and left out a few stages. They then made resolving the tech debt part of their sprint. The product won't suffer, and the debt will be cleared. If they leave their tech debt unresolved and ignore it, then it will build up and eventually lead to an unreliable product.