Technical Debt has got to be one of the most misused terms in software development and I myself had it wrong for a very long time. This is the evolution I've been through, and where I currently sit with it.
Where it started
Before we get to the real origins, let me take you through how it originated in my head. I've subscribed to a few definitions over time!
I first heard the term technical debt when I was a junior developer, interacting with teams who were maintaining lots of legacy code. Due to this, there was a growing initiative from middle managers for their teams to reduce their technical debt. This brings us to...
Definition 1: Legacy Technology
Technical debt is synonymous with legacy tech. If you have lots of legacy tech that is expensive to maintain and hard to change, then you must reduce that technical debt.
This definition was easy to learn since it was a pure definition of a tangible thing rather than a concept. And it was all I ever knew until I was told otherwise!
Pros of this definition
- Reducing technical debt sounds much more appealing than dealing with legacy technology so it might speed up decisions to deal with problems
Cons of this definition
- It is reactive. It offers no insight into how problems are caused in the first place
What triggered me to rethink my definition
- I got hot on the fact that everything we write as developers is someday going to have to be modified or deleted and in assuming that technical debt is a thing that we must get rid of, I concluded very confidently that...
Definition 2: Everything is Technical Debt
Every line of code will one day die, and it will cost effort to kill it. So in assuming everything we write is technical debt, we can be mindful of the cost of creating and deploying.
While this is quite reductive, let's explore it:
Pros of this definition
If we adopted this mindset, then we might be more sparing in the code we write. Think of the "overproduction" or "extra processing" lean wastes.
It will reduce your ego! No matter how unbelievably beautiful the code you write today is, one day it will be as decrepit as something written in the context of the 1990s might be today. As you write your code, you might now consider how easy it would be to delete it.
Cons of this definition
It might cause people to be nihilistic. What's the point in trying to do a good job if it's eventually going to be deleted anyway?
The opportunity cost of not leaning into the metaphor
What triggered me to rethink my definition
- I realised it had absolutely nothing to do with the idea of debt. Why was this term first coined? Someone must have had a metaphor in mind
Definition 3: Getting back to the metaphor
Financial Debt
What is financial debt? It is borrowing money now, with the requirement to pay it back later, often with interest.
It can be bad; unconsciously racking up credit card debt so you can get a fresh wardrobe ready for the summer, with no plan to pay it back might get you into a lot of trouble.
But taking out a business loan to buy some equipment so you can start your new manufacturing business might pay itself back multiple times over.
The difference between these two cases? Only one of them uses the debt to invest in something that will make more money in the future, so you can pay back the debt, and end up with more money than if you hadn't taken out the debt in the first place.
The same applies to the metaphor of technical debt.
Technical Debt
If you unconsciously go faster than your constraints should allow you when developing a new application, then something will have to give. The code might be substandard and hard to maintain. And if you've done this unconsciously, then you might never repay the technical debt by bringing the code up to standard.
On the other hand, if you take shortcuts in your coding to deliver something in a short time frame, you may get buy-in from the business resulting in them investing more in your idea.
BUT! You must be conscious that one day, that debt will have to be repaid, or else interest will accrue. Every day that goes by, more workarounds will have to be made, and something that should take 1 hour to do, ends up taking 3, all due to the substandard code that was written in the first place and never dealt with.
With every decision to move faster than your constraints allow, be it financial or ability, you must make a plan to pay that back as well as the interest that goes along with it.
Definition 3 is the one I've settled on organically and feel comfortable with in my head. It has the benefit of being quite close to the real idea too.
The actual origins of Technical Debt
Ward Cunningham coined the term around 1992 but his most in-depth exploration of the concept is in a video he released almost 20 years after. Rather than for me to try and fail in paraphrasing his ideas, I'll point you to where you can watch or read about his ideas directly.
Conclusion
In my experience, Definition 1: Legacy Technology is by far the most widespread definition people subscribe to, but it misses out on the main point.
Definition 2: Everything is Technical Debt might have some ideas to extrude, but it shouldn't be associated with the term technical debt. It waters down the real idea unnecessarily.
I'm settled on Definition 3 for now, and given it was the original one, something revolutionary would have to come along to dethrone it.
Reading the actual idea behind technical debt by watching Ward's video straight away would have got me to my answer quicker.
But you know what? I learned a lot from my discovery along the way and each of the definitions contributed to my thoughts on developing software.