Tech Debt Simplified

Technical debt (or tech debt) is a concept that is often misunderstood by those new to Agile development (and sometimes those that are not so new). It is a common misconception that tech debt is that "little bug" found in your code right before the end of the sprint that you don't have time to fix. That's absolutely not the case. That's a bug...a defect, plain and simple.

Let's break down exactly what technical debt is in order to better understand the concept. Ward Cunningham first coined the phrase back in 1992 when he explained the refactoring process using the metaphor of debt in a paper on the WyCash Portfolio Management System.

"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." - Ward Cunningham

Keep in mind that he's not saying that it is acceptable to allow a few bugs into the code as long as you can ship it promptly. He's saying that taking a "quick and dirty" approach that gets the job done with the intent of going back to clean up after yourself allows the product to get to market quickly.

photo credit: Cool Syntax Highlighting via photopin (license)

A "bug" is something that doesn't work as intended...something that makes your Definition of Done (you do have a Definition of Done, right?) not complete. I'll assume that one part of your Definition of Done is that your code passes all tests. If that is the case (and it should be), then that user story is not done. If you say "That bug isn't that big of a deal, we'll fix it in the next release," that isn't technical debt. That's a bug, my friend.

Ideally, we would always have time to build out a future-conscious design that may take longer to implement, but is the cleaner solution. However, this isn't always possible with time constraints and, let's be honest, we don't always (almost never) have a clear vision of the future state of the system that would allow us to know exactly how to architect it in a way that is future-proof.

Keeping with the debt metaphor, the longer technical debt remains without being refactored, you gain "interest" on that debt. That means that, if left alone, your once minor tech debt will eventually become a huge issue that impedes future development efforts. Tech debt needs to be addressed and "paid off" as quickly as possible.

One of the easiest ways to manage your tech debt is to devote a certain percentage of development efforts to refactoring, or "paying off," tech debt. A common practice in Agile development is to devote 20% of development time to tech debt. This might mean that you devote every 5th sprint to tech debt or that you include 1 tech debt user story for every 4 feature stories in each sprint. How you do it doesn't necessarily matter. What's important is that it gets done.

How does your team handle tech debt? Have ever experienced a case where tech debt was left unchecked and turned into a project in and of itself?