Technical debt is a metaphor
Extreme Programmers (XP-ers) like to use metaphors or analogies for the systems they are working on so that they can communicate with their non-technical customers, fostering better collaboration and co-creation.
When Ward Cunningham coined the term technical debt, he was working on a financial project. He wanted to communicate to his manager why the first-cut of the software would incur an amount of rework.
The metaphor Ward created was in intended to show that for any software product we develop, we increase our understanding of how it will really work as it moves through the development lifecycle.
Knowing that we don’t know everything up front and that we’re not going to fill in the gaps until we start, we err on side of doing sooner and learning as we go. The ultimate feedback in terms of our product’s usefulness comes after we’ve shipped a working increment. We can then discover from our customer, in a close-to-real world situation as possible, how we can improve it.
To explain the situation to his manager, Ward likened this to borrowing money:
With borrowed money, you can do something sooner than you might otherwise, but then until you pay back that money you’ll be paying interest. 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, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.
Ward Cunningham
Using Ward’s analogy, the less investment you put in up front, the more debt principal and interest you’ll have to pay back if the idea turns out to be a good one. This same attitude to learning is applied in The Lean Startup using the Minimum Viable Product (MVP) approach, in his book Eric Ries entreats us to think about the MVP as the beginning of the Product lifecycle.
And while there is a deliberate amount of learning (known unknowns), there is also a certain amount of unexpected learning (unknown unknowns) that can happen, and this is where real game-changing moments can happen.
So at some point, we have to decide if we’re going to incorporate those learnings back into our software. If we do then we reduce the “debt” and increase the usefulness of our software.
If we don’t, we accumulate increasing amounts of software that doesn’t perform its job as well as it could. Each time we go to make a change this slows us down, either because we’re busy reconciling the debt in the area we’re working in, or because we’re working around it.
If we allow this gap to widen further, the harder it will be to make changes and the less useful the tool we’ve created will become.
Eventually, our software will become redundant because it no longer fits the purpose it was intended for. It will be replaced and we’ll lose our initial investment completely.
Just like any borrowing, it’s not just the size of the initial loan that needs to be taken into consideration, but also the level of interest that is accumulating due to the ongoing impact of the “borrowed” time. A small loan can quickly get out of hand if the interest rate is high.
So it’s important when we considering borrowing time (and money) that we don’t enter in to it lightly, we read the small print and fully understand the terms of the loan. To pay down the debt effectively we have to be disciplined in our approach and just like any loan, we would look to make regular repayments.
In software terms, this means we fully understand before we commit to taking a loan, why we’re doing it, what are we trying to learn.
And just because we’re borrowing time to learn something now, it doesn’t mean we write sloppy code.
Instead, we write code to reflect our current understanding of the problem in a clean and simple fashion as possible (remember the Agile Principle: Simplicity – the art of maximising the work not done) – this will better help us refactor it when the time comes.
As Ward puts it:
…the ability to pay back debt, and make the debt metaphor work for your advantage depends upon your writing code that is clean enough to be able to refactor as you come to understand your problem.
Technical debt is a specific metaphor
Remember, at the beginning of the article I pointed out that Technical Debt is a metaphor. I also mentioned that metaphors and analogies work well in a technical context because they allow us to communicate and share ideas with non-technical people using a common language.
Technical debt, however, is a specific metaphor created for a financial project, and although this particular metaphor’s use has expanded out to other contexts for technical people, non-technical people still tend to struggle with it.
In my experience, the word debt strikes fear, its sounds like we have lost money before we’ve even started. Isn’t it our job to seek and help create value?
Instead of using this term I propose creating a new one that makes more sense to the whole team. To do this we have to have a system metaphor that works for us and then look for a technical debt equivalent within its context.
One way to do that is to think of your software product as if it was real life, physical product.
If you’re building a publishing system for online media, the system metaphor could be a printing press.
For an online retail experience selling shoes, the metaphor would be its bricks and mortar equivalent. It could be a market place, or maybe a High St store, or even a shopping mall. In this instance, the equivalent technical debt metaphor would extend to the shop premises.
For example, consider a shop in its early proof of concept stage. All we’re concerned with is that people want to and can buy our products, so we start very simply with the software system equivalent of a market stall.
Once we’ve proved that there is a market for our product, if we don’t go back and improve our shop’s infrastructure, fixtures and fittings, e.g fit out of the shop, including shelving units, shop layout, signage, or ability to expand our business, then as the shop’s popularity starts to increase, we’ll find it increasingly difficult to service the increasing number of customers and their different needs.
If we start to improve the shop as we go, in particular how it’s designed and built, we’ll find it is overall more responsive to the expanding business we find ourselves in.
The easiest way to do this is to work at improving the shop’s ability to act as a shop, while implementing new features. If we treat our code as the shop’s design, and our build process as the shop’s physical manifestation, it’s structure and outfitting, then we can be see how this might work.
Rather than seeing ourselves in debt, in fact we’re seeing how our shop could evolve to better serve its customers, and how the infrastructure, the space, its layout and outfitting of our shop could be better improved to serve our customer need to purchase our products.
The shop metaphor, its infrastructure, premises, fixtures and fittings is just one potential alternative metaphor to technical debt.
My challenge to you is to determine the metaphor for the software system that you create and maintain, then consider what the equivalent would be in your context.