Should we stop discussing about technical dept with top management | Viaplay Group

Thank you. I come here with a question for all of you. Should we stop discussing about technical debt with top management? And this is something like a question that has two parts. Something like, they really understand us. And the second is, we are explaining the right thing. So I will try to answer my own question. But first, let me introduce myself. I'm Pablo Bouzada. You could find me in LinkedIn because my name is not so common. I am Spanish. And I'm in Germany at [inaudible] the last three years. But previously, I have a career of more than 20 years. And previously, I worked more than 12 years as a consultant in more than 80 companies. My main work was answering questions for my customers, my users. Why? Why this is taking so long? Why do we have that amount of bugs? Why is my thing not well-trained? Why is it always DNS? But today I will focus more on that technical debt because it's something like you usually use that term. A couple of weeks ago, there was a survey released in The New Stack, a really good platform with blogs, that surveyed 1,200 engineers who said that they want to code but they are almost spending all day paying technical debt. And when C-level people, not technical people, go and see or read that kind of things, it's something like, what the hell is technical debt? What is it talking about? Because the article said that developers spend 84 percent of their time paying technical debt, working on technical debt, working on maintenance, and then not in new features at all. I will start with that, and then based on my experience as a consultant, I will refer to real conversations that I had with not technical people, not always stakeholders, not always C-level, but not technical people that don't understand technical debt. I will start from the very beginning. It's something like when we are talking about specific technical things, we can use our own language, our technical language. When we find something like it's really hard to change code that is not maintainable as well, we could talk about orthogonality, we could talk about cyclomatic complexity, we could talk about coupling, cohesion, about databases we could talk about the form that this database is on, the first, the second, the boycott, four, five, six, something that is between the five and the six and so on. But this is something that not many people understand. People say, wait, wait, wait. Don't talk confusing to me. You know, because when you are quite deep in technical jargon, people lose. In the industry, you have that metaphor. A metaphor was released, was invented by Ward Cunningham in the early 90s. He said that the technical debt is something he tried to explain to his manager. His manager was more on the financial side. And then he tried to explain that they are able to do something quick that will have consequences in the future. He said like, okay, we are going with that solution that is not the best, but we know that with that solution we will achieve the deadline, but we have to pay that technical debt in the future. So technical debt refers to the implied cost of additional work in the future resulting from choosing an expedited solution over a more robust one. We're choosing something we know is not the best solution, but that will speed up our development maybe, but this always comes with a warning. The warning is like, while technical debt can accelerate development in the short term, it might increase future costs and complexity if it's left unresolved. And this is an important part of that. Because technical debt per se is nothing wrong. It's nothing like if we deliberately make time dedicated to cleaning or refactoring stuff, educate the stakeholders about the impact of technical debt in a proper way, not just: we have a lot of technical debt. Oh, yeah, yeah [inaudible]. No, we have a lot of technical debt. It's something like an excuse. Like, you are not doing things because you have a lot of technical debt. So it sounds like, the dog ate my homework. Something like we need to be fair with the things that we are doing. And well, something that works really well is like follow the Boy Scout rule, like leave the ground cleaner than you found it. Every time that you touch something and it's something proper, it's something like could be improved, go. Not like ask for permission for that thing. It's something like take the ownership of the code because it's our domain. Just a recommendation about the thing, like we need to speak with people in the terms that they know, so they are able to understand. If they understand the technical debt metaphor, go for that. If they not, not continue with the same thing, not continue like a broken record, and then technical debt, technical debt, technical debt. Try to find a different way to explain. If you are sure that you are in some of those cases, that is not like the good ones, so go for trying to fix the root cause of the things. Is it this the pressure from product people? Go for that. If it's the lack of knowledge, go for that. Is it the lack of maintainability or the high rotation in the teams? Go for that kind of things. If it's lack of documentation, this is the root cause. The technical debt is a metaphor first, but also it's an abstraction. It's not always the same. It's something like we have a generalization of what's happening when we make decisions and then in the future impact that. And now that's all. Thank you so much.