Watch this episode on YouTube.
Reasonably Accurate 馃馃 Transcript
Morning everybody. How are you doing today? On this episode of the show? We're gonna talk about technical debt and how it's impacting your customers and your security. Now, if you're not aware of what technical debt is, it's the term that refers to all of the bugs, all of the design decisions, all of the old code and architectures that are eventually weighing down your product or service moving forward.
Ok. So essentially when you build out a new feature, you need to make tradeoffs and as those tradeoffs sort of age, they gather um challenges, they make it more difficult to move forward. They're very much like financial debt. That's the analogy there is that you're making decisions and you're making tradeoffs and at some point somebody's going to come and collect.
Now, you're probably wondering why is Mark talking about technical debt. This is a channel, this is a series of videos dedicated to privacy and security. Well, it's gonna get weirder for a second and then it's gonna all come back around. So please bear with me here. I was reading an article um on uh CBC news about the CCTS, the commission for complaints about television and Telco something or other.
Um, it's a commission here in Canada where people who are unhappy with their service about internet, about uh mobile or, um TV, can complain to try to get some sort of remediation when they haven't been able to go through customer service um, from the uh provider now, much like a, a lot of uh countries.
Uh, here in Canada, everything is sort of consolidated. So you go to the one company can give you internet cell phone as well as TV. So no shock to anybody. This commission gets a lot of complaints. In fact, that was the whole point of this article is that complaints are up somewhere north of 44% in the last few months.
Now, the interesting thing is when you dig into a lot of these complaints, um, not many of them are actually about the technical service. The technical services are good. It's about the cost, it's about the, the contract and a massive amount about billing issues being promised to pay one thing and having bills for others.
And this, the reason why I bring this up is it actually reminded me, uh, now I have contracts with two of the biggest uh providers here in Canada. And anytime I've dealt with either of them, I am baffled by how old and Byzantine, their billing back ends are inevitably they've got three or four different screens and they tell me like, oh, this one user space is really just plastered over the old command line interface.
And sometimes I have to call somebody else who has a different interface back into the system. They're a mess and that holds true with any Telco or any ISP um or mobile provider that I've really dealt with um across the world. A lot of the back end billing systems are rag tag at best.
They're kind of slapped together and they're very much neglected. Now, the reason for that is that as long as they're collecting some revenue, hopefully the accurate numbers around revenue they're often overlooked. Because if you have a limited set of engineering resources and all companies do have a limited set of resources, you are going to divert them towards delivering new functionality or keeping production systems up.
Very rarely is the billing system a high priority. So it totally makes sense from an engineering perspective. You're like, no, no, just let it go. We found a bug that's fine. Here's a workaround and we can set out new training for the support staff. Um You know, and that's why you end up with these people who have sort of this magical knowledge where they say, well, if you enter code, uh you know XYZ here and you put 123 in this field, then you can actually get the price that you promise the customer to be displayed and this that and the other thing.
And that's a clear example of technical debt. But it's one that's being worked around more often than not with people instead of actually addressing that debt. And I thought that was really interesting was that this come up in any of the discussions around the rise in complaints um with the service providers was the fact that their billing systems are widely out of debt and it's extremely difficult or widely out of date and in huge amounts of technical debt and it's very difficult to justify making an investment there when they're trying to roll out five G to everybody when they're trying to upgrade their internet speeds to match fiber to the home, things like that.
Now, what does this have to do with security? It has everything to do with security because security issues, security vulnerabilities rise from unpredictability in code and a lack of general code quality. So as you see a rise in technical debt, you're going to see an equivalent or a larger rise in security vulnerabilities and security issues.
Now, unlike technical debt, in the case of the service providers where they can throw customer service people at it and the impact is potential financial. As we're seeing with the rise of complaints in their customers when it comes to security issues, that's an increase in risk and it's often an overlooked increase in risk.
And I think that's where things get really, really interesting because if you go around and talk to security teams, almost none of them are talking about technical debt, they'll say, oh, that old system, you know, every time we go talk to them about it, they have an excuse, but they're not actively involved in the discussions about paying down technical debt and refreshing old systems.
Now. Don't get me wrong. I 100% understand it's extremely difficult to divert resources that could be forging a new path forward to something that the customer will never see. But my argument here and the evidence from the commission is that customers do see it. They just see it in a way that you're not tracking related to the technical debt.
Because if you go back to this idea of the service providers and the complaints and billing and the complaints in dealing with their back end systems, that's totally outside of its purview that's dealt with uh call time for the call centers. It's dealt with customer service. I guarantee you it does not link back to it and internal engineering resource men.
And that is the core of the problem is that you have one arm of the organization making decisions saying, oh no, this technical debt, we're fine. The system is still working, we're still processing bills. We're another area. In this case, customer service is losing their bloody minds. We have the same thing going on with security as well because security is not involved with the application and the engineering resources when they're making decisions around paying town technical debt.
We're not making the proper risk evaluation here and organizations are continuing to increase their risk without fully being aware of it. What do you think? Let me know, hit me up online at Mark NC A in the comments down below. And as always by email me at Mark N dot ca, I look forward to chatting with you about technical debt and we'll see you on the next episode of the show.
