Organizations and software development teams investing in DevOps culture and tools must take inventory of their current technical debt and how they plan to address future technical debt. Over time, software teams that do not effectively manage technical debt become burdened with slower software cycles and spend more time paying “interest” on the debt, just to keep the software working. This “interest” diverts resources away from implementing new features, makes it more difficult to automate builds and deployments, and reduces the benefits of adopting DevOps.

What is Technical Debt?

The term “technical debt” was coined to describe the costs of taking short-cuts or the “wrong” approach to creating functional software in the short-term. In other words, it’s a design decision that is fast now but requires a fix or more support in the future. These short-term decisions result in code that is more difficult to read, modify, extend, or maintain in the future. While all technical debt has a cost, not all technical debt is bad. Let’s examine the different types of technical debt developers may encounter:

Acquired Technical Debt

When product managers and development teams take over an existing software system or project, they inherit all of the decisions made by the previous team. The current team may not have chosen to code or implement the same way or may have the benefit of knowledge that was not available to the original team. This type of technical debt is acquired technical debt.

Unintentional Technical Debt

The next category of technical debt arises from either honest mistakes or sloppy coding. An honest mistake could be building an app that cannot be easily updated to support a new unforeseen platform. Sloppy coding introduces technical debt because it introduces bugs and maintenance effort into the software development cycle. With unintentional technical debt, the development team does not make a conscious choice to take on debt.

Short-Term Technical Debt

Business leaders and development teams may consciously make decisions to take short-cuts or do things the “wrong” way in order to ship a product more quickly. In this situation, the benefits and costs of taking on technical debt should be part of the decision-making process, along with a clear plan on when to address the technical debt after release. This kind of intentional technical debt can be beneficial to organizations.

Long-Term Technical Debt

In other cases, development teams may choose to take on technical debt for strategic purposes by delaying developmental costs and efforts. One example is building an app that supports a single platform while planning to support additional platforms after the organization raises the next round of VC funding. Similar to short-term technical debt, document the reasons for incurring debt and when the team will address it.

Inventory Your Debt

It’s challenging to pay down technical debt that you don’t know you have, so if you choose to incur debt for short- or long-term strategic reasons, be sure to track it. If you take over an existing project with acquired debt, add the debt management tasks to your list of development activities.

Some organizations track technical debt in the product backlog, and some track them as defects. Regardless of how you choose to track technical debt, implementing code standards and automating both development and testing tasks can reduce the amount of unintentional debt you accumulate during future development.

This is Part I in a 4-part series on Managing Technical Debt.