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?”

There are answers to technical debt problems. First, it is imperative that you identify your technical debt. There are tools that can evaluate your existing software code and estimate levels of technical debt. If your IT department is not using them, force them to do it. If they can’t, hire someone who can.

Next, if you are building software products, start thinking about them as software products. Add technical debt (and technical debt remediation) to your backlog. Work on the debt that is causing the most issues. There are ways to refactor the code so that it increases code quality and decreases debt. If your IT department does not know how, hire an expert.

If we view products as products and stop thinking about them as short-term projects, we will make the investments necessary to create quality code. Enhancements will be easier, defects fewer, and releases more frequent. If we keep chasing bright shiny objects without fixing the underlying code, we will continue to create more debt and pay higher and higher interest.

Lastly, now that you now about the silent killer, make sure that you adopt the software development practices necessary to insure that excellent code quality is baked into the product. Adopt BDD/TDD and Continuous Integration and Delivery.

And always keep in mind the old lament: “How come we never have the money to do things right the first time, but we always have the money to fix it later?”