Technical debt is often the elephant in the room that we choose to ignore, but we do so at our own peril. Technical debt is directly responsible for many of the problems we have in building high-quality software quickly, especially as companies move to more agile methodologies. Having problems releasing quickly? Can’t complete your testing in a single two-week iteration? Defects leaking into production? Development taking much longer to complete than it should? Chances are good that you have a high amount of technical debt.

“Technical debt” is a term coined by Ward Cunningham as a metaphor to help non-development people understand software development issues. It is sometimes also referred to as “design debt” or “code debt.”

(Related: How to curb your technical debt)

Here’s how the metaphor works: Suppose you have a bit of functionality that you just have to deliver quickly. You have a choice to develop the software using best software development practices, or you can cut corners to deliver sooner. If you cut corners, then you’ll incur technical debt. In other words, technical debt is generally the sacrifice of quality for speed.

In this example, the debt is strategic in that a conscious decision was made to create debt. Think of a credit card; I buy something now at the expense of my future buying power. I will be charged interest on that debt and it would behoove me to pay that debt as quickly as possible.

Technical debt has its own form of interest. If you have ever wondered why that “simple fix” takes way longer than it should, then you are probably paying a high interest on your debt. Suboptimal code can result in more defects, longer cycle times, less confidence in the code and longer testing cycles, and it can even (because people dislike working with bad code) lead to employee dissatisfaction and developer turnover.

How big a problem is technical debt? Gartner estimates that technical debt will reach US$1 trillion dollars by 2015. I worked at one place where the technical debt was estimated to be equal to their entire yearly IT budget! If you are in the business of software development, you should care about technical debt because it is a silent killer. It manifests itself in ways that are difficult to measure but radically impactful on your bottom line.

High amounts of technical debt mean that your software takes much longer to develop than it should (just image all your projects’ budgets cut in half), is of lower quality (how can we measure the number of customers lost to poor quality?), and takes longer to deploy to customers (how can you be agile, and how many customers are lost to long deployment windows?). You can see why people might shy away from these discussions! It raises some very uncomfortable questions like “Why didn’t you tell us about this before? How could you let the code quality become so poor?”