In 1992, Ward Cunningham came up with ‘technical debt’ as a metaphor for the consequences of choosing to ship imperfect code:
"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt."
The debt metaphor is useful as it explains the future cost of faster delivery today. Unfortunately, most of the time I hear people talk about ‘technical debt’ the metaphor is ignored, and the term is used as a catch-all for imperfect systems. To overcome this, I suggest we use alternative metaphors for the different scenarios.
Imagine you are cooking a meal for friends and you are running short on time, you might not wash up as you go along, instead filling the sink with dirty utensils, pots, etc. If you don’t wash up after the meal, the next time you cook there may be a few clean pots, but you will inevitably have to wash up a few things. If you keep on failing to wash up after the meal, it takes progressively longer to cook - having to wash up what you need every time.
It gets worse – as you try to retrieve something at the bottom of the festering pile of washing up, with stacks of plates teetering in the sink, sometimes you knock something over and it smashes on the floor. It’s risky work. The smug chef will wash up as he goes along, that way everything is always clean and ready to use. This is sustainable, predictable and most efficient.
The software equivalent of this is that there may be a good reason to hurry something out of the door – maybe you cannot learn whether a new release helps users until it is deployed. If you ‘wash up’ after shipping (and learning) then you are in a great position to start ‘cooking’ the next release. If you don’t ‘wash up’ – it gets harder to make changes and you slow down, and the code becomes more fragile, with unintended consequences when things are changed (broken dishes).
The smug chef’s “washing up as you go along” means that code can always be worked on as quickly as the day it was started. We don’t always want to maintain that ideal though – the guests are arriving very soon, and that’s when, as engineers, we can choose to leave the washing up in the sink and sort it out after the release. To me that’s what technical debt means: choosing to incur a future cost, to do something faster today. If you don’t pay it off though, the interest payments get bigger and you eventually run out of cash.
The ‘debt’ analogy works – and it’s shorter than ‘not doing the washing up’ but perhaps we need to talk about washing up, not to get tangled with what people sometimes mean instead.
What people often misuse ‘technical debt’ for is describing an imperfect system that has been worked on for quite a while. Over time, limitations will have been found, and better choices could have been made - maybe usage shifted, hindsight is great etc. The analogy of having chosen to take on some debt and then pay it off, just isn't the case. When people say that the system has a lot of ‘technical debt’, do they mean that there were trade-offs that were made to ship earlier, or just that the business has evolved, the software has been built upon, new technologies emerged, and it isn't perfect?
Whether or not we switch from talking about technical debt to dirty washing up, the more important thing is a descriptor for systems like this. What should we call it? I dislike the connotations of 'legacy' and it is demotivating - it doesn’t respect the people who built it, or that it continues to serve a purpose. ‘Continuity systems’ sounds like management speak. It is more akin to a nineteenth century house - it probably doesn't have double glazing, and maybe there isn't enough hot water, but that's because of when it was built and maybe only some of that can be fixed. Whatever it is, it certainly slows down development, and is some sort of ‘brakes’ or ‘drag’ – it just isn’t ‘debt’.
So what should we call this?