A couple of years ago, I was talking with a good friend of mine, we were talking about the difficulties of prioritizing the maintainability of software in a large organization development context.
And so, logically, the concept of ‘Technical Debt’ came up. Interestingly, he had never heard the term before, although as soon as he heard it, he grasped the importance.
(I remember it as being a really inspiring conversation, but sadly, my notes from that day don’t well capture what I found so inspiring about it. 🙁 )
Although the concepts of ‘clean up after yourself’ and ‘do it the right way’ are likely as old as human civilization, it was likely only after systems reached a certain level of complexity that the concept of ‘Technical Debt’ was really useful. There is a limit to how complex a mechanical system can get, and most other systems are amenable to human factors and psychological safety solutions.
It’s also interesting to think about what is different about software, that makes it: A) possible to make a working product with large (including conceptual) defects, B) Useful to ‘go into debt’ to get a product out the door faster (or more cheaply).
One wonders how much it is the sheer complexity of software systems, the number of interacting modules, or perhaps the number of layers involved, from OS to dev_tools, to language, to standard libraries, to 3rd party libraries, to user-made helper functions. Perhaps it is just that one can ‘go into debt’ in the uppermost layer, because there exists a good foundation.
It could also simply be that software is an automation of so many smaller tasks, that any human system as complex would have similar useful concepts of debt.
Doing a little bit of digging, it seems that the concept was first termed ‘debt’ sometime in 1992, but it was not until later that it was termed ‘Technical Debt’.
Articulating the concept of ‘Technical Debt’ has a number of important benefits:
1) It puts a name on the category of ‘things we want to clean up in our code’, adds an urgency, and calls out more precisely why this is important.
2) It links the concept of ‘do things the right way’ with ‘Business’ concepts of money. This enables much better CTO-CFO conversations, allows better and more informed project funding decision making, and (hopefully) enables better and more structured funding for Technical Debt reduction.
3) It enables conversations in the moment, during architecture conversations and code reviews (and everything in between), where the parties involved can directly weigh/balance the time/resource costs of proper implementation with the opportunity costs of delaying time to market (or MVI/MVP).
It will be interesting to see how organizations (and organizational decision-making) change as this concept spreads from ‘pure’ software companies.
 We theorized that this was because he had grown up in Hardware companies.
 I am not a Mechanical Engineer, and I’m happy to hear counterexamples, as well the conceptual frameworks used to address this… 🙂
 Such as ‘Organizational Debt‘.
 https://www.martinfowler.com/bliki/TechnicalDebt.html “As far as I can tell, Ward first introduced this concept in an experience report for OOPSLA 1992. It has also been discussed on the wiki http://wiki.c2.com/?ComplexityAsDebt.”
 My favourite label for this is the ‘FBI’ list, as in ‘Can you F****** Believe It?’, passed down to me by an executive from a famous Canadian software company.
 ‘Minimum Viable Increment/Minimum Viable Product‘, from various implementations of Agile theory.
 Things that might linger on a list like this include things filed ‘Too Dangerous to Fix’, which are often interesting memoir fodder.