In this podcast episode, Johna and I discuss the concept of technical debt. We provide different definitions of technical debt, with me focusing on the inability to switch solutions easily and Johna emphasizing the trade-off between immediate speed and long-term efficiency. We give examples of technical debt, such as outdated systems and insecure infrastructure, and discuss strategies to avoid or manage it. Johna highlights the importance of having a plan for sunsetting technology and managing technical debt in the context of digital transformation. We also draw parallels between managing financial debt and technical debt, emphasizing the role of architecture in making informed technology decisions. The episode concludes with a discussion on good and bad technical debt and the need to address it strategically. We invite you, our listeners, to reach out for support and engagement in further discussions. Transcript Greg (00:00:00) – Welcome to heavy strategy. The place where unanswered questions is better than unquestioned answers. Basically, the point is that we are keep going on a topic and agree to disagree. And the idea is instead of sort of agreeing how wonderful we are and going with the status quo, let’s try and find if there’s some other insights or some other side of the discussion that we can’t necessarily find. So if you’re here, Jonah and I argue strongly, maybe debate like good old high school debates, then that’s what you’re in for. Today’s topic is technical debt. This might be one of many or it might be one of one. I’m not 100% sure how this is going to go. Jonah, I started off talking about in my notes saying, how do you define technical debt or what is it? And I went through a different sort of tactic to what you what I said. In general, for me, technical debt is the inability to easily interchange one solution with another with minimal cost and impact. That is, I’m visualizing that there’s some sort of a solution inside of infrastructure. Greg (00:00:56) – Could be a database, it could be a website, it could be, you know, some sort of business solution. And for me, technical debt is the inability to move away from that if you so choose. But you want it to go into a much higher level of detail. So I’ve stated my side. Now let me shoot a shot at yours. Greg. Johna (00:01:15) – I would say that your your definition of technical debt is actually a corollary. The impact of true technical debt. Technical debt has a technical definition. It was the phrase was created by a guy named Ward Cunningham, who’s a programmer who developed the first wiki and kind of, for better or for worse, jumpstarted the concept of Agile. And he described it as the trade off the programmers make between immediate speed and long term efficiency. In other words, technical debt is when you go do something because it works at the time and never change it, never go back to change it to ensure that it’s aligned with your broader architecture and is, as you pointed out, interoperable and has all these other capabilities. Johna (00:01:56) – It’s like, let’s make it work for the solution at the time. Yeah. Don’t think about the bigger picture. And then downstream, what happens is the problem that whatever the technical debt was created to solve may have gone away, changed, morphed. But the technology is still here, sitting there like a lump in the middle of your infrastructure. Greg (00:02:14) – So I think Cunningham was referring to in that sort of circumstance, like in his era, the language that people often just rapidly prototyped in was Perl. But Perl was not a good long term decision and running code. Johna (00:02:27) – No, it really didn’t have to do with the language at all. And the thing to keep in mind is something that you did to solve an immediate problem th...