Introduction

Technical debt is one of the most insidious and damaging phenomena in software development. If left unchecked, it can destroy projects, products, entire software organizations, and even companies. Anybody that has worked on software intended to live for more than a few months is familiar with the signs that it has taken root:

• Making changes to code seems to take longer and longer over time
• There is low confidence in the quality of the software because changes often lead to regression bugs, and so a fear of change develops
• The code is hard for anyone (even the author) to understand
• Maintenance activities, such as updating dependencies, are almost always significant undertakings, and so the codebase is increasingly out of date
• Release cycles are in weeks, months, or even years

These are undesirable traits leading to an inevitable end-state where all forward progress halts.

So if tech debt is so dangerous, why do software organizations allow it to accumulate? You would think that organizations would make it a point to prevent it. If only it were this easy!

In this article, we’ll explore some of the reasons technical debt accumulates and look at a few approaches to manage it better.

Definition

The term “technical debt” was coined by Ward Cunningham in the 1990s:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

- Ward Cunningham, 1992

To paraphrase: technical debt boils down to all of the shortcuts that development teams have taken during execution and never loop back to address. It can refer to subpar code, weak architecture, brittle infrastructure, sloppy development processes, or any number of sub-optimal work. The buildup of these things always results in friction in the development workflow, with the result being that it takes longer and longer to change or add code until development progress stops.

Another way to think of tech debt is from the Lean perspective, which is to see it as a form of waste in the system. There is much more to the concept of waste in Lean thinking, but for our immediate purposes, we’ll say that waste is anything in our workflow that does not help us deliver value to our customers. Tech debt certainly falls into this category because it directly inhibits our ability to progress through our workflow at a reasonable speed.

Whatever you call it, technical debt is not something we want to be overwhelmed by. Let’s attempt to understand it a bit better so that we might think of ways to avoid it.

Cause & Effect

A Tale of Two Teams

We won’t be starting our discussion by talking about the evils that lead to technical debt (don’t worry, we’ll get to that later). Instead, we’ll use a couple of scenarios to tell the all-too-familiar story of how one team’s (Team Blue) attitude towards technical debt can have a massive negative impact on its trajectory and contrast it with their counterparts (Team Green). This example is by no means a precise model. It merely describes the general order of events and the effects. We can use this to compare one team that ignores technical debt with another that embraces the practice of addressing it incrementally.

As stated before, this is a generalization of what might happen. Often the decline isn’t as steep as drawn here. It can be much more gradual over a more extended period. It’s drawn like this because of the opposite case where there is a tech debt “wall” of sorts. It can manifest through the sudden realization that debilitating debt has crept up on the team, and an overriding sense of urgency emerges to address it. For example, management might insist that tech debt be focused on once they hear that changes that were taking days now take a month.

Sometimes there is a more obvious breaking point where forward progress completely stops until the team addresses some issue. What follows is a ripple effect where addressing the main issue means some other seemingly peripheral issue first needs to be addressed, which itself requires yet another problem to be solved. This situation can arise in cases where core dependencies are left too long, and the upgrade becomes urgent and painful. Either way, the scope of the work has expanded because tech debt was allowed to set in.

If you’ve experienced any of these situations yourself, then you’ll recognize some of the effects that technical debt can have. If you identify more with Team Blue, then this article is for you.

Let’s take a closer look at some of the causes and effects of tech debt.

#devops #agile #software-engineering #technical-debt