Technical Debt, Loans & Costs

I listened to The Ultimate Metric: Identifying the Right Problems to Solve. The guest,  Janelle Klein, said:

Technical debt is not a loan

I thought that was brilliant. She went on to explain that when we talk about “debt” managers think they have dials to manage the debt.

Uh oh. Wrong.

When managers think in cost accounting terms, such as mortgages, they think they can:

• Predict the cost of maintaining that debt, in both money and time. (Do nothing to pay off or manage that debt.)
• Predict the cost of paying off that debt, in both money and time. (Do something. Often add more people.)

But technical debt isn't like a mortgage. You don't pay it off and end up with something that often increases in value.

If you don't pay off the technical debt and/or if you allow the debt to increase, you might end up with something with less value than you started with.

In normal circumstances, we expect houses with mortgages to at least maintain their value—if not increase in value—over the life of the debt.

If we're smart about car loans, we expect we have many more years of life in the car once we're done paying off the car loan.

Software isn't like houses or cars.

A software product is the instantiation of what the team learns up until now. See Why Do We Estimate, Anyway? When the team learns more and releases that learning, the product changes. We hope we created more value. We don't always do so.

The more we allow our technical debt (and I prefer Doc Norton's term of cruft) to persist, the more it affects the rest of the code and the product:

• We can no longer easily add functionality.  Cycle time increases.
• The builds might become circular. Cycle time increases.
• The tests at every level become more complex or they miss edge cases. Cycle time increases.

Worse, keep the technical debt and everyone starts agitating for a rewrite to avoid developing anything else for that particular product.

Technical debt is not a cost we have not yet paid off on a product that increases in value over time. Instead, technical debt—cruft—decreases our ability to add more value to the product over time. That's the increase in cycle time problem.

The technical debt/cruft does not help us rewrite or rearchitect the product better the next time. The insufficiencies in the code and tests make it much more difficult to see what to change.

Since too many managers think about technical debt as a kind of mortgage, let me offer another frame for that debt: the balloon mortgage on a house.

In both kinds of mortgages, you pay the same amount a month. The difference is at the end of the balloon period. At the end of the balloon, you owe a lump sum payment of the entire remainder of the loan. Contrast that to a normal mortgage, where the bank expects you to continue paying the loan for the rest of the loan period.

Here's an example: Assume you take on debt of $100,000. Both loan types mean you pay $506.69 each month. The difference is if you have a balloon mortgage of 7 years, you owe about $91,000 as a lump sum at the end of 7 years. In the 30-year regular mortgage, you owe about $99,000 but the bank expects you to continue to pay over time. Much of the interest is front-loaded.

It's all about the expectation of repayment.

In software, we expect we can continue to add features and support the product with tests. If we can't, the cruft becomes a balloon payment where we need to start a rewrite or re-architecture with not much notice.

Technical debt is not a loan. Technical debt incurs a Cost of Delay for future work. You borrow against the future to keep cruft in the product now.

Technical debt/cruft creates a drag on everything the organization might do.

I don't run my business that way. Should you? Maybe the first step is to rename it so managers don't think that kind of debt is like a mortgage.