David Gammel asked the following in the comments on my previous post on technical debt:

Do you think the technical debt has to be paid off with a balloon payment? It seems to me like you can’t really pay off this kind of debt on a 30-year fixed interest model, it all comes due at some point in the future and must be paid in full, at once, in order to move beyond it.

Or can you refactor code consistently and in essence pay it off with small payments over time?

I think it very much depends on the form of debt. As a matter of habit, whenever I work on code in an application that seems difficult to understand or badly written, I take the time to try to improve it where possible. I think that constant weeding and pruning are the key to maintaining a nice code base, and nobody seems to know or mind when what would have been a one hour fix turns into a two hour fix because you went ahead and made things a little better while you were in that code anyway.

On the other side, there are cases where technical debt has to be paid off all at once. For example, one application I work on is still running on Rails 1.1.6. Rails is now at version 2.3, and there have been a multitude of changes that would make this application easier to work on. Unfortunately, migrating up to the latest version of Rails is going to take a fairly substantial chunk of time, and it all has to be invested at once.

In both of these examples, good unit tests are the key to being able to pay off the debt at all. In the first case, making “improvements” to the code while you’re working on it can be risky if you don’t have the tests you need to insure that you haven’t broken the business logic in an effort to clean things up. In the second example, having a solid suite of automated tests makes it possible to rapidly locate and repair all of the problems you run into when making a large set of changes.

I suppose then that I’d argue that inadequate tests are one of the most painful types of technical debt that a project can accrue. On the upside, it can be paid off gradually.

The other day I was reading an article by Martin Fowler in which he referred to the term technical debt. He credits Ward Cunningham for coining the term, which is defined thusly:

Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

This is a nice, business-y way to discuss a problem every developer is familiar with. You could publish a blog just on ways projects incur technical debt and how to address those problems. In fact, I’d argue that one of the primary jobs of a team leader or manager on a technical team is to spot places where technical debt is being incurred so that it can be addressed later on.

The burden falls on the person leading development, because nobody else involved in the project is going to take care of it. The product manager (or project manager) are properly focused on budget, schedule, and specifications. The quality assurance team is focused on making sure the application produces the right output given the right input. Only the developers themselves can be responsible for reducing or avoiding technical debt while addressing the other audiences.

I think that most of the worthwhile fights that developers have with other members of the team are over issues of technical debt, it’s just that few people refer to it that way.

Expect more posts on technical debt in the future.