RedMonk published a great article today on the incompleteness of technical debt as a metaphor. This touches on a number of points, the best one I think is that for many people in business, debt just isn’t a “bad per se” thing. Technical debt, more often than not, is.

I completely agree with the analysis. Presenting technical debt as risk is a more accurate picture a lot of the time. While it’s potentially even more accurate to relate them to other financial instruments (my favourite is the “uncollateralized technical debt obligation”), it’s much more difficult to relate to.

I’d like to share the simile I use.

Most people have read “A Christmas Carol” by Dickens, and are familiar with the story. This is the piece of story I go from:

“You are fettered,” said Scrooge, trembling. “Tell me why?”

“I wear the chain I forged in life,” replied the Ghost. “I made it link by link, and yard by yard; I girded it on of my own free will, and of my own free will I wore it. Is its pattern strange to you?” (1.98-132)

I know, a grim picture.

I used to talk about technical debt in terms of karma, or drag, and this picture helpfully combines aspects of both. In development, we wear the chains we forged in previous sprints.

Sometimes we add links to our chains, and because they’re small links they don’t slow us down too much. In fact, a small shiny chain actually makes us look pretty cool – it’s a bit bling.

You can over-do the bling, though – spend too much time on the shiny and you begin to look a bit like Bobby George. Ok, it’s not weighing down the throwing arm too much, but it’s not great for much else.

And beyond that, we’re chained down and can’t really go anywhere. Each additional link we add to our chains slows us down that bit further until eventually we can barely move.

Adding links

Much like karma, we can add links to our chains by both action and inaction. Most people are familiar with the actions – marketing need a snappy new landing page, but to get it out in time we need to put a gross hack in which makes us throw up in our mouths a little.

Inaction is equally important to get across, though. I’m a big fan of running on zero bugs – of course, you never actually get there, but every bug you ignore becomes a link on the chain. Many times they’re small, sometimes they’re big.

I once was working on a product that had a bug tracker full of known issues. As a multi-tenant SaaS application, it was also pretty common that issues would be seen by multiple customers. For every bug that got out, it would probably be seen by four customers minimum, and that overhead would initially be borne by customer support. They may or may not identify it correctly, so we might get further bugs added to the backlog. And the customers would need to deal with the problem somehow – often with a workaround that changed the system somehow.

For each little bug we didn’t immediately fix, we would spawn a bunch of work and duplicate issues, plus a set of ad-hoc changes to customer instances often. We added a bunch of links just through that one inaction – in fact we could quantify it. Talking about the number of bugs in the tracker as links on a chain, and how quickly the chain was lengthening, brought things home to people quickly – because it wasn’t the only chain we were wearing.

Removing links

Everyone talks about “paying down technical debt”. If only it were that easy! We can spend a bit of money on any debt, and so long as we’re paying off more than the interest, things are improving. That’s not always the case with technical debt.

Anyone who owns a bike in London understands there are many different qualities of chain. Many are easy to cut through, some are virtually impossible. There are some that are stupendously difficult to get through; they tend to have large, hardened links and are often found wrapped through the wheels of quick motorcycles.

So it is with the chains of development. In many instances it is much easier to add the chains than remove them.

In technical debt terms, this is like going into debt with a loan shark. They want their money back quickly and with substantial interest, otherwise life becomes very painful indeed. It can take significant effort to do the work to pay down.

What I think is fun about the chains of development metaphor is that it highlights one important property: that sometimes (not always), we can cut through one link, and that automatically causes the rest of the chain to fall off.

I’ve seen this a few times in development; you build up a bunch of debt in a system. It can be worth paying that down, but at some point it can also become worthwhile to just replace that system. This is especially true when you only need to replace part of a system’s functional scope in order to decommission it fully.


There’s no perfect metaphor. Each comes with positives and negatives; and the advantage of speaking about “technical debt” is that it’s a term that most executives know.

I find it’s often useful to change metaphor depending on the context: obviously you never want to mix them, that would be like crossing the streams. But, if you have an easily quantifiable decision, “technical debt” can be appropriate. If it’s less quantifiable, then “technical risk” is better. And if the problem is the “death by a thousand cuts” of cumulative small decisions, then “chains of development” is a handy metaphor as well!