Empowering a connected society
June 2024
Have we overloaded the term ‘technical debt’?
What do we mean by technical debt?
These days, we seem to mean a lot more than Ward Cunningham did when he first coined the term in 1992. As Cunningham has helpfully clarified, he was specifically referring to coding choices made in the absence of full information – information that could only be gained by releasing a version of the code and learning how it was used. The technical debt incurred in this way could be paid down by refactoring the code as its full feature set became apparent – or could be ignored, at the risk that, just as with financial debt, servicing the debt would become all-consuming: developers would spend all their time navigating an ever more complex code base, full of incrementally added and contradictory concepts.
The idea of technical debt is powerful, and intuitively appealing to anyone who has developed software, or managed or sponsored a software development project. It is so appealing that we have used it in many more adjacent contexts. I have seen the term ‘technical debt’ applied to:
I don’t believe that this widespread use of the term ‘technical debt’ is bad in itself. The core concept – that we sometimes have to make compromises that we must pay for later – is sound, broadly applicable and has explanatory power. However, I also believe that casual misuse of the term is dangerous, and leads us to excuse technical debt or accept its persistence.
Credit, the financial concept on which technical debt is based, is a useful tool which makes our economy possible. It enables us to move value across time and space. It enables me to buy something today which I will not be able to afford until tomorrow.
But it is easy to let the habit of spending on credit get out of control, especially when you can’t see the balance and you don’t know the interest rate. Once the concept of technical debt as a conscious choice exists, it is easy to incur debt for bad reasons: the project manager only cares about this release, so we’ll test minimally and manually; the sponsor really likes this particular technology product and, well, they’re the boss; the release schedule is full this year, so we’ll push the upgrades to next year. Putting the consequences on the technical credit card becomes a habit.
Furthermore, just as most companies usually require some form of borrowing, to invest, or grow, or acquire, we can easily fall into the trap of thinking that technical debt will always be with us. Our systems will always be a bit out of date; our architecture will always be a bit of a mess; our code base will always be a bit difficult to understand. Paying the interest on this persistent debt becomes part of what we do, until it consumes or overwhelms us.
The form of technical debt that Cunningham originally wrote about was not an excuse and was not intended to be persistent: you cannot know everything about the desired behaviour of your system until you make a release, and the experience of that release will teach you that you would have done things differently if you’d had all the information. Small amounts of technical debt, paid down quickly, are an inevitable part of software development. But this is not how most organisations think about or manage their technical debt.
Perhaps one way to help us stay in control of technical debt is to ask ourselves: who are we borrowing from? In one sense, just as with all credit, we are borrowing from our future selves. But this doesn’t fit the metaphor: with true debt, there is always a lender, and it is that lender who makes us pay. I think that when we incur technical debt, we are borrowing from the systems we are building and the architectures we create. And, if we are not careful, they certainly make us pay.
