Technical debt is real, and teams need a strategy to manage it. Just about every software project accrues tech debt over time. Tech debt manifests itself during development and in production. Ignore it or don’t service it at your peril.

Before continuing, let’s look at a simple definition of tech debt. The one I like goes something like this: Technical debt is the difference between what was promised and what was actually delivered. This includes technical shortcuts made to meet delivery deadlines, whether inadvertent or not.

Tech debt sneaks up on codebases and is insidious in where it hides and the problems it causes. While some tech debt is planned, most is not. The longer a team waits to address tech debt, the harder it is to refactor. Over time it burrows into a codebase, making it more and more challenging and time-consuming to manage.

Studies have shown that a codebase reaches the tipping point when there’s 60% tech debt. At this point it becomes hard to recover from. This is, of course, an extreme situation, but even lower percentages of tech debt are challenging. Software cannot adapt fast enough in the face of a meaningful amount of tech debt. Above all, it impacts productivity and morale. It also makes codebases harder to maintain and extend.

The first step is to stop adding to the accumulated tech debt. That is, all new functionality will be written according to “professional coding guidelines.” In addition, all code, old or new, will be reviewed.

From the agile perspective, every story developed and any work being promoted from the backlog should not increase tech debt. Teams and individuals generally know how to write clean code, so this needs to become the ongoing practice.

The accrual of tech debt negatively impacts and is in direct conflict with agility. Accessing and reducing tech debt is a key part of any agile program. Along with code-specific issues, architects who don’t know how to design extensible architectures and programmers who don’t know how to write clean code are issues that must be addressed.

Where technical debt comes from
Tech debt is one of those pay-me-now-or-pay-me-later kinds of issues. While there are no good reasons to incur tech debt, there are reasons teams knowingly add to it. Unrealistic project deadlines and stakeholder demands often lead teams to sacrifice quality or take shortcuts they normally wouldn’t. Teams promise to remediate the issues after release, but this doesn’t always happen.