The term “Technical Debt” is 25 yrs old
The original concept of Technical Debt is also very out of date.
I read an article from Redmonk generally awesome person Rachel Stephens about Technical Debt. It is a superb article:
The article challenges whether or not the concept of Technical Debt is as useful now as it was then.
I think the tech landscape has significantly changed since the concept was created.
25 years ago we had long projects, code delivery solutions in the months and years.
25 years ago Linux was only a year old.
25 years ago we didn’t have widespread broadband and the ideas of Open Source and sharing code were only really just beginning.
25 years ago we didn’t have Virtual Servers, Cloud, Agile and DevOps.
I think these things change the equation for Technical Debt. 25 years ago code was based around a long time between builds and development teams without the same level of commoditisation of code through frameworks and access to the massive number of “other coders” on the internet.
I think the article is brilliant though. Most techies don’t really understand technical debt as a concept and certainly not in this way. Most of the time Technical Debt is thrown around as a broad concept around “introduced bugs” from previous work rather than a conscious decision to do something in a less careful way.
Nowadays we have Agile and Lean and the idea of an MVP and access to serious numbers of other coders who can help, which means developers are now more conditioned to build “throwaway” code anyway and find “answers” from the internet rather than developing their own skillsets. The huge amount of shortcuts taken by developers now (frameworks, build scripts etc) and the idea that things can often be relatively fast to rebuild due to abstractions like services means that technical debt in the 1992 sense is often never really paid.
I do think a new term is needed. The more I look at frameworks, the more I realise that utilising the larger frameworks can have huge benefits for developers in terms of a “common language” between them, but it can also introduce real Technical Debt. It is still a shortcut.
But the Technical Debt from a framework may be a debt that never gets repaid.
And then is using a framework a debt or a solid financial decision?
Maybe it’s a much more long term debt like a Mortgage. Something that can easily be refinanced (rebuilt in another way) later without a significant loss of value.
I have to say, I’m not a big one for financial metaphors. But Technical Debt is so vague nowadays, and used in so many contexts, that I’m unsure as to how helpful it is any more.
But I’ll probably still use it.
