This site will look much better in a browser that supports web standards, but is accessible to any browser or Internet device.
September 23, 2006
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.
Posted by GWade at September 23, 2006 12:36 PM. Email commentsMuch applause for this musing/entry. I know how much you have done in the cause of "technical debt reduction" and this article really resonated with my own reflection of upper managements disassociation with the true cost of "code and implement now" with little regard for the true cost of expediency vs. resilient and pliable solutions.
Where I work, a cheesy solution was accepted over a more elegant one that took ONE DAY longer to implement, but no effort was made to take a step back and recode the front end for the better approach. The options were discussed up front but management made it a “race to implementation” vs. “what is more flexible in the long run”. I can only grin and watch as the more flexible solution would have made the “new problem” trivial instead of another hack on top of the old one (not to mention slowing down the servers even further).
One key point that I have finally begun to understand here is that the motivation for ignoring the cost of the quick solution may not be stupidity or bloody-mindedness. In reality, the reason is more likely to be misunderstanding of the cost. As far as they see it, the programmers are babbling about inelegant code and not focusing on the real issue of the bottom line.
I think that the people who have posed the concept of technical debt are attempting to put what we developers know into language that the business types can understand. If both groups are speaking the same language, there is the possibility that we can stop butting heads.
I'm also hoping that the concept of voluntary technical debt will help me to be less pig-headed when it comes to an adequate solution needed for business reasons.
Posted by: GWade at September 25, 2006 07:08 AM