Technical debt considered useful

I have debt: a mortgage on my home and some credit card debt. Is debt a “bad thing”? Well, yes. In the sense that I would much rather not have to pay off my mortgage every month. If I didn’t have a mortgage I’d have an extra bit of cash left every month that I can do far better things with.

But was my mortgage useful to me? Hell, yeah! Without it, I probably wouldn’t own my own home now and if I rented something comparable, the rent would in all likelihood be more than what it costs me to service my mortgage at the moment. I’m not so sure about my credit card debt though – as useful as the facility is, sometimes you can get it wrong in how you use it.

Lately, I’ve heard many of my colleagues throw around the term “technical debt”. The term is in common use now, especially in terms of agile projects. “We cannot sustain this velocity without incurring technical debt” is just one example of how I’ve heard it used recently. Incurring technical debt is a “bad thing” and even Wikipedia seems to agree: Quoting from its article on technical debt, Wikipedia notes “…The build up of technical debt is a major cause for projects to miss deadlines …”

This extract from Wikipedia’s article on technical debt appears to imply that technical debt is a little different from my mortgage: technical debt is a major cause for missing project deadlines. On the other hand my mortgage helped me to own a home faster than I would have otherwise been able too. Perhaps I am stretching the metaphor too far here in comparing technical debt with financial debt?

In this video, Ward Cunningham explains how he originally coined the debt metaphor to explain to his financial software bosses the need for refactoring. He also says that he was very aware of the power of metaphors to influence thinking after having read Lakoff and Johnson’s book “Metaphors We Live By” and that he believed that this particular metaphor was entirely appropriate to reason about technical debt. And so the process of (thoughtfully) incurring technical debt is not unlike my mortgage and can in some cases help get the job done faster. It can sometimes help meet those tight project deadlines.

That is not to say that financial debt, like technical debt, cannot be abused. Possibly like my credit cards, although I’m not quite drowning in debt yet. I can afford my repayments and can still live in relative comfort. But I need to take care to make sure I keep making progress towards repaying my debts while controlling my spending. A little controlled debt is a good thing, as long as you are aware of it and handling it responsibly.

Thanks to the genius of Ward Cunningham’s metaphor, technical debt behaves a LOT like ordinary debt. However no metaphor is perfect and there is an important difference: financial debt is exact while technical debt can be fuzzy, qualitative rather than quantitative. My bank can tell me to the cent exactly how much I owe and what my monthly interest is. I also know exactly what my monthly income is and how much I will have left after debt payments. On the other hand, technical debt can be hard to quantify and it can even be subjective. I have witnessed heated disagreements between developers on whether a particular bit of code or design is a paragon of leanness and simplicity or technical debt that needs to be addressed as a matter of urgency. There is no precise number to quantity technical debt or the interest payments, or even the remaining “disposable income” to spend on developing software. Sometimes the process of reducing technical debt in one area introduces some in another. This does not make the metaphor any less useful though.

The perfect scenario (there are others) where introducing technical debt is the right thing to do is the startup trying to get version one of the first beta out the door to get revenue flowing or to unlock further investment. Any startup, fully understanding the concept of technical debt, will have zero qualms in taking on technical debt – just ship it and we’ll fix it later.

In the video mentioned above, Ward Cunningham himself says: “I thought borrowing money was a good idea. I thought that rushing software out the door to get some experience with it was a good idea. … eventually, you’d have to go back and refactor your program to reflect your experience as you’ve acquired it.” Emphasis mine.

In conclusion, Martin Fowler in his technical debt Bliki summarises this far better than I could: “The [debt] metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.