Technical Debt is what makes code hard to work with. It is an invisible killer of software, and must be aggressively managed. In this post I define Technical Debt and describe some of the issues. In the past, I have stated that the ScrumMaster’s #1 issue on a Team is likely to be getting the Team to write Quality Code, which is code that the Team can change easily. I noted that we (as an industry) know how to write such code, by using XP-like practices. Unfortunately, we often fail to do so. Technical Debt is the stuff in and around the code that keeps it from being Quality Code – that makes it hard to change. In other words, the term ‘Technical Debt’ refers to the debt that is owed to the code before it can become Quality Code. Often, people use the term ‘legacy’ (or even ‘instant legacy’) to refer to code with large amounts of Technical Debt.
I think of Technical Debt as being the viscosity of the code; it is what makes the code hard to wade through. One of the best metaphors I have for Technical Debt is that of going for a run. Working with Quality Code is like running in the park, in good weather, with shoes that fit. It is comfortable, and the Team can move quickly and with confidence. I like to refer to this a ‘6-minute code’ since it takes about 6 minutes to run a mile when it’s nice out, the course if flat, and you’re a pretty decent runner… On the other hand, there is ‘4-hour code,’ which refers to how long it takes to trudge a mile in the swamps, with a pack on your back and water up to your belly-button. The ratio of 6 minutes to 4 hours is 40, which is a reasonable (if anything, too low) estimate of how much more difficult it is to work with terrible code than it is to work with quality code. If you’re a coder, you know what I mean…
Definition of Technical Debt So, let’s take a closer look at Technical Debt. The overall concept is pretty clear; it’s the stuff that makes code hard to change. As you can imagine, this is a tremendous drag on agility, and having high amounts of Technical Debt is probably the number one impediment to Teams being agile. To be specific, having code that the Team is afraid of is the number one killer of agility. Technical Debt is not just about the code, though; there are other factors that come into play:
- The code can be hard to change because of the quality of the code itself
- Lack of technical documentation
- The development environment
- 3rd-party tools
- Procedural impediments
- Organizational issues
- And even the skill-level of the Team itself
Since it is the ScrumMaster’s job to help the Team remove impediments, each of these issues is something the ScrumMaster should worry about.
So, my definition of Technical Debt is: Technical Debt consists of deficiencies in the code, technical documentation, development environments, 3rd-party tools, and development practices, which makes the code hard for the Team to change.
Learn more about how to prevent technical debt, the types of debt, and read about a dirty code horror story.