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.

Review of Programming Ruby

Programming Ruby
Dave Thomas, Chad Fowler, and Andy Hunt
Pragmatic Bookshelf, 2005.

This book has taken me a really long time to finish. It's not because of the writing. The writing is clear and readable. The material is well-presented and seems to cover the topic well. I don't see any glaring errors or anything that I didn't like about the style or presentation. Despite all of that, there appears to be something missing.

Over the years, I have taught myself over a dozen programming languages from various books. Some books were better than others. Some languages I learned because I wanted to, some I learned because I had to. With everything I've been hearing about Ruby, this sounded like a language I would want to learn. Unfortunately, this book did not give me a compelling reason to use Ruby.

Don't get me wrong, the book makes a wonderful reference. It also provides a very good tutorial. It just doesn't compel me to use the language. Different languages have different strengths, and different personalities. This book did not tell me these things about the Ruby programming language.

If you have a real need to learn Ruby or you are already driven to use the language, this book will definitely fill in what you need. If you are like me, you will probably need something else, as well. Despite that, I would recommend this book to anyone who needs to work with the Ruby language.