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.<\/p>\n
And so, logically, the concept of ‘Technical Debt’ came up. Interestingly, he had never heard the term before[1], although as soon as he heard it, he grasped the importance.<\/p>\n
(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. \ud83d\ude41 )<\/p>\n
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[2], and most other systems are amenable to human factors and psychological safety solutions.<\/p>\n
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).<\/p>\n
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.<\/p>\n
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[3].<\/p>\n
Doing a little bit of digging<\/a>, it seems that the concept was first termed ‘debt’ sometime in 1992[4], but it was not until later that it was termed ‘Technical Debt’.<\/p>\n Articulating the concept of ‘Technical Debt’ has a number of important benefits:<\/p>\n 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.<\/p>\n 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[5].<\/p>\n 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[6]).<\/p>\n It will be interesting to see how organizations (and organizational decision-making) change as this concept spreads from ‘pure’ software companies.<\/p>\n [1] We theorized that this was because he had grown up in Hardware companies.<\/p>\n [2] I am not a Mechanical Engineer, and I’m happy to hear counterexamples, as well the conceptual frameworks used to address this… \ud83d\ude42<\/p>\n [3] Such as ‘Organizational Debt<\/a>‘.<\/p>\n [4] https:\/\/www.martinfowler.com\/bliki\/TechnicalDebt.html<\/a> “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<\/a>.”<\/p>\n [5] My favourite label for this is the ‘FBI’ list[7], as in ‘Can you F****** Believe It?’, passed down to me by an executive from a famous Canadian software company.<\/p>\n [6] ‘Minimum Viable Increment\/Minimum Viable Product<\/a>‘, from various implementations of Agile theory.<\/p>\n [7] Things that might linger on a list like this include things filed ‘Too Dangerous to Fix’, which are often interesting memoir fodder.<\/p>\n","protected":false},"excerpt":{"rendered":" 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[1], although as soon as he … Continue reading On the Importance of ‘Technical Debt’<\/span>