Programmer Musings

The Concept of Technical Debt

I have recently being seeing references online to the concept of Technical Debt. The concept is an attempt to explain to business and management types some of the downside of overly complicated designs, lack of testing infrastructure, and quick-and-dirty code written to meet a deadline. In the past, I've had trouble explaining the difficulties working with this kind of code. Some management types have dismissed cleanup effort as a waste of valuable time. I have often been told that we don't have time to waste on the theoretical benefits of elegant code. One time that I got this response, I was talking about the practical downside of violating encapsulation. This is not a theoretical benefit to the maintenance programmer searching a large code base for the spot where instance data has changed unexpectedly.

In the past, I have had the fortune to work with a few people who understood and worked to clean up the nasty corners of a code base. In each of those cases, we were able to reduce the time spent on maintenance and extend the code to support new business requirements. Despite the successes, we often had to contend with people who claimed that it could have been done anyway and that the cleanup was wasted effort.

I now believe that the problem was an inability to express the problem in language that the business could understand. Technical debt may be the language that we need. It may also help stave off the more aggressive or idealistic programmers (including myself) that have taken a strong stance against any form of technical debt.

I recall the first time I understood the business need for some technical debt (although I didn't think of it that way at the time). I was arguing with the founder of the company about a really nasty hack that he wanted me to put in a piece of code. This guy was not just a management type, he was also a prolific programmer. After quite a bit of explanation of each of the downsides, he finally said: I know all of that, but we will have to live with it to satisfy this customer. At that point, I realized that he not only understood the problem, but he also personally understood the pain we would incur from this decision. He also realized that we might be able to fix it later, but the debt (and interest) was acceptable for business reasons, at this time. I feel the understanding I gained in that discussion truly improved my programming ability.

It may help to rephrase the debate in terms of the amount of technical debt the company can afford and how to efficiently pay off technical debt at appropriate times. The talk Get out of technical debt, by Andy Lester, does a really good job of explaining the costs and how to reduce technical debt. On the other side, James Shore talks about the benefits of temporarily assuming debt in Voluntary Technical Debt, as well as the concrete cost accrued because of this debt.

Like financial debt in business, technical debt can be used as a tool to solve a problem in the short term. But also like financial debt, if you don't pay off the debt in a timely fashion, the interest can eat your business. This concept of interest payments for technical debt is not perfect, but I think it might help to explain the problems that we programmers actually see with those issues covered by the term technical debt.

A lot of the businesses I've seen and worked with appear to be in technical debt up to their eyeballs. Some of the companies wonder why they cannot make much technical progress with their code. What they don't see is that this is similar to borrowing all of the money they possibly can from the bank and any other investors they can find and then wondering why all of their profit is going to fees and interest.

Hopefully, this analogy will help us to make progress towards better code that doesn't suck the life out of programmers and companies.