The term technical debt often gets used by development teams to help communicate to the business the impacts of poor code quality on the team’s velocity as a way to justify to the value of fixing these problems.

The metaphor is based on the concept that poor quality code has an ongoing cost to the business (interest) and that we can reduce this interest by spending time improving the quality (repaying debt).

The analogy falls apart in a few ways:

You pay interest on a loan no matter what, but we only incur a cost to code that we are making changes to;

Real debt never goes away, but technical debt goes away when you retire your product;

A business doesn't need to repay debt to have a successful growth model, whereas technical debt may cripple growth if left unchecked.

The last point is where the analogy falls down hardest, because it damages the underlying goal of communicating the costs to the business. A business manager may be thinking how valuable it is to acquire technical debt to get the product out the door quickly and think this is a viable long term strategy.

When we deliver a product, even a poorly constructed one, we have invested in infrastructure. We have built something and we are making revenue off of it.

If I ask you to build me an apartment building, and I put you under pressure you may cut corners. As a result there might be issues with the foundation, leaky plumbing or shoddy electrical work. In the end I will be able to rent out the apartments, but at a reduced price. The cost of repairs will also be much higher than if I had taken the time to do it correct from the start.

As the owner who has asked for this work to be done, I’m going to be very annoyed that you as a professional didn't build a high quality product. That being said, I've still got a choice to make. Do I spend the time and repair these issues, or invest my money into my next development project.

That all depends on the return on investment; does the increase in rent justify the cost of repairs? The payoff may be great, because my decrepit apartment building may only be rented to those with the lowest incomes, but the repairs may be so extensive that it never becomes economical.

In software, the cost of rework is extremely high. To fix problems, it may require rebuilding a module entirely. The payoff, however, may be much higher. The poor infrastructure may be preventing me from building new features, or building them quickly.

If we talk about our technical debt in the form of infrastructure investments it may allow our profession to better communicate the impacts of rushed work to the business. Spending the time to repair our code is an investment that can allow us to build features faster and has a high ROI. This analogy also emphasizes the importance of building it right the first time.