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, - well, 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 we have that amount of bugs? Why my thing is not well-trained? Why it's 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 that was released in The new stack. It's a really good platform with blogs, - that survey for 1,200 engineers that 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 don't 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 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 worth in the future. Resulting of 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 that decision, - in the future we need to solve that technical debt - and implement a better solution. Okay, this is fair. No problem. But what happens when we left that technical depth in our systems, - not just in our code, because as Camille mentioned this morning - we are not talking just about technical systems. We are talking about the whole organization systems. Also, to answer the question, - we need to go a bit deeper in what technical debt means. And I will use that - technical debt quadrant that also - Martin Fowler defined that quadrant that I think is brilliant, - the way that he defined the things. And said the thing, like, this is the origins of technical debt. The technical debt, - as WardCunningham defined it, - is we must ship it now and deal with the consequences. We know what the consequences are. We know how much time we need to - spend to fix that thing. But now this is the solution - that will provide like that, - hitting that deadline or, - ensuring that that customer are with us or something like that. Okay. So it's for a business goal that we are making that decision. So Martin Fowler defined that quadrant and said like, - that specific kind, the original technical debt is - deliberate and prudent. So it's not too risky. And it's something we know that we are doing in that way. And we all know that we are doing in that way. Okay, this is fair. They're good technical debt. Okay. But what happens when... Because as I define it, like, - it's a decision we're making now that will affect us in the future - if we do not solve it. But what happens when we are talking with not technical people and - find something like that? Stop discussing about the past. Let's focus on the future. This was a real conversation I had with a product manager - who's a bit reluctant to pay the technical debt, - to spend time fixing technical debt. Preparing that talk, - I found that image. I think it's the best description of technical debt. And if you have enough time in the industry, - you will know the intro story of what's happening here. Because this is typical stuff with. Technical people and a not technical person or a manager - that is just focused on the future. Something like also - Camille mentioned this morning, like being a future factory pushes you to - do things that you are not sure that are good or not in the best way and so on. But I could read the story. It's only one image, but I could read the story. And the story is like a typical company that started out, - oh, we have the best product in the world because we will provide - the thing that the user want - in a way that have never been. And we have really great ideas of that. And we have the best thing for doing that, a whiteboard - and a lot of post-its. So first thing in that history, - as a user, I want a front door to enter my house. Okay, done. We have front door. Second user story. As a user, I want, - a bit posh, and I want a couple of columns to bring that classic - vibe to my house. Okay, I'm not sure where to set that columns, - but we are building the walls, - and that wall is a bit, not straight at all, - so why not set here and there the columns and wait - as a user for feedback. Okay, - then the project continues. People start working - on the walls, - in the front part of the house. But also another team, - because we're not to speed up, so we add more people to the project. And then other people will start working on the backyard, - on the back of the house. And then, you know, like... Both parts need a roof, and they have their own implementation of a roof. But as you see, they are not connected. So we have feedback from our users. Please fix the water leaks - that come through the roof when it rains. Okay we need to fix a thing quickly and instead of complete the roof and - having only one permutation of the thing we decide oh why not to use a - SAS, okay why not to use a service that provides it like that solution and then - we found that thing, - umbrella company provide us something like it's not just... Instead of build it, we buy it. And then it's something like, - we'll provide cover on that part of the house that is leaked. It's something for that. And then it also is a [inaudible]. So it should be a good solution for us. And then we finally get that - user story that come for the last thing. As a user, I want a window to look to my backyard when I take in my coffee - in the morning. Okay, and then we are here. We had the manager saying, I don't understand why it takes so long to add - a new window. And the response is easy. It's because our walls are not completed. And then the manager say, okay, - why are walls are not completed? Why are in that state right now? Why nobody told me that our walls are not completed? And then you go to the backlog and see something like that. A technical story created two years ago, - low priority, merged front and rear walls. And that technical story also has another subtask, - because we like creating subtasks. Make the wall thicker to hold windows. So this is why we are not able to set windows in that house. This is a really good example of what Martin said here. We are still in the deliberate row, but we are in a different column. We have no time to design a better solution. And then he said that thing like, - okay, this is deliberate because we are making that decision knowing, - more or less, what are the consequences. We are postponing things. But it's risky. It's reckless. We are taking so many risks doing that thing. And this is - more or less the most useful thing when we have a lot of pressure from - the product side, from stakeholders. So instead of going for the best solution, - we are taking a lot of shortcuts. And the thing is like, okay, this is technical debt. But when you try to explain a thing to non-technical people, - usually the metaphor have a weakness. Like thinking like technical debt works as financial debt. That is not true. And I also had that conversation with a - non-technical person that said: honey, that's not how loans work. And this was my wife. My wife works in a bank and they know I have a master degree in - economics and so on. So they're like, oh yeah, okay. I will explain to you how financial debt works. This is something easy. If you take something like a financial debt with a - long term balance of 100,000 euros, - a long term as 60 months, - because why you say it's five years, 60 months is good. We are counting like children. Interest rates of five percent you will - pay 1,887, every month. And then you know the consequences when you are not paying. You will get a email from your bank, - your risk will rise, - you will not afford other payments, - and so on. Now we know, like, - finally we will pay an interest of 13,000 euros, - and then the total amount will be - 130,227 with 20 cents. Okay, so everything is... This is a financial debt. But what happened with technical debt? With technical debt, - our long amount is... You know, it depends - on the technical debt, because not all the technical debt are the same. Our long term is - when we have time for doing nothing. The interest rate is, - how long we could not fix the thing? How long we could stay with the solution that we have now? Because this will change a lot, the interest that we'll pay. The monthly payment is, okay, - product owners or product managers, - how much we can spend on that each sprint. We think like 20 to 40 percent is good. Then we'll see if we have enough for saving - or not having a big problem, - big bugs or something like that. The total interest depends on other priorities, - for sure. It's something like, okay, depending on when we pay, - we will spend more or less time on that. And the total amount is, who knows. Because this is something like only happening with technical debt, - or specifically happening with technical debt, that there's a lot of unknowns. And when - that two kinds of technical debts is quite clear that this is something - deliberate and usually we know exactly what we need to fix and more or less - how much that will take. But the problem is when we add another row here, - that is the technical debt that is not deliberate. It's something like a [inaudible] call inadvertent. It's something like when the thing is not aware that the harm that some decision - will make in the future. And also we have two groups here. Something like is prudent, - is something like, oh, we don't know that we're - doing that thing that we did in the past, we had that issue. Now we know, and then we could fix it in a proper way. But the most problematic one is the other one, - is that it's inadvertent and risky. Because it's, okay, what's lagging? What are you talking about? Something like, is this a modern way of developing software? So you will find a lot of the things when you're trying to refactor - really all the stuff. This is what Martin Fowler said because - we do not have only one kind of technical debt, - and also in the same company, - we could have a mix of the themes. Some things will be here, some things will be there. It depends a lot on the maturity of the team or the maturity of the company. It depends a lot of the - culture inside the company, like just pushing, - just going forward, moving forward, - no complaints, just doing stuff or no, - no, everything has to pass through a really bureaucratic stuff and then it will - be like in different states. The thing that is common is what happens when we have unmanaged - technical depth. And this is when we start talking seriously with - non-technical people. This is the moment that they realize what the problem is - and what are the consequences. And manage technical debt, technical debt that is not resolved, - is increase the cost of ongoing maintenance. And also add new features, because every feature is something, - I want to do that thing, but it's something - with the walls and the window. My walls are thinner than the window, - so I'm not able to do that thing. Second, it's like querying technical debt into production - could raise risk in the outages and security breaches. Something like, oh, we could go with that solution, - and then we find that that solution was - insecure or create other issues in the system. Third, refactoring become riskier because every time that we touch - something inside the system, we break other stuff. And the same, - like modification in production, - carry with a higher chance of causing disruptions. And I think for me, it's one of the hidden ones. It's not that clear because that are clear. It's not like touching something that is so-so will create some problems. But I think the last one is the hidden one, - that the productivity declines and delivery slows down because people - are waiting all the time fixing things instead of working new features, - something like they are more motivated to do. So that adds stress to the teams and - can lead to reduced motivation and higher staff turnover. So when you have that thing and you present that thing with technical debt, - not just, okay, we have technical debt. How many technical debt? A lot. How many is a lot? A huge technical debt. I don't know how to measure that thing because we don't have a - measurement for that thing. It's something like we have a lot of - technical debt here, there. This thing is something that is more prone to have - issues and so on. But when you show to non-technical people that thing, - then you get that final conversation. It's evident that things were not - executed as they should have been. Let's take decisive actions to rectify - this situation and forge a path toward a better outcome. Okay, this is a real conversation I had with a - CEO of a company. C-level people talk in that way sometimes. Maybe not here in Denmark, because we are quite more direct, - but you see people talking that way. You know executives or C-level - expect to see diagrams with lines going up to the right, - with green numbers, with positive deltas and so on. When you come with something like, we have huge technical debt, - something like, okay, but what that means? What they want to see is, okay, you are bringing me a problem. So I want a solution. I want a plan. I want objectives. I want goals. I want a budget. Something like, how we could handle that thing. This is where the metaphor technical depth - is something like we need to go further, - a bit further of that metaphor, not just, - oh, we need to pay the technical debt. What might that cost? You know, 500 millions. No, it's not. It's something like we need to change things in the system - to fix that thing. Several things. But I think if you have to take something for - that talk, it's the next slide. Okay. The issue we're trying to solve is not paying the technical debt, - but increase the internal quality of the systems. This is the main point. Technical depth is something like we are using for - explaining stuff, but it's not like what we need to fix. What do I mean with internal quality of the systems. When you are adding functionality - to a system that has low internal quality, - you could at the beginning start moving really quick and add a lot of - functionality and a lot of features, but you risk the technical debt. When technical debt smashes you, then you will stack in that point. When the internal quality is good, - you will be able to maintain the ability to easily and safely implement changes - in the system that is continually evolving. And this is the most important thing, that technical debt will affect you - in the future. You don't know when, but it will affect you in the future. When you are trying to do something in some specific part of the system, you - will find that technical debt that we never fixed is there waiting for us - like an animal behind a tree and then gets all of our expectations. So how could we do that? This is the second most important thing on that talk. How we could do that? How we could go from unmanaged to managed - technical debt? So the goal is like reaching the prudent deliberate. Something like, there is where the teams are safe to test new things and - do stuff that could be quickly fixed. And you could see that there is not a direct way for going to left button - to the top right. You will never do that thing. You will never pass from inadvertent risky to prudent deliberate. So you need to grow. You have to grow your team. And for doing that, for that level, - you need to invest in hiring training. You have to ensure that the teams are following good practices. You need to set guidelines - for factory legacy code, and also you need to improve - feedback, internal feedback and external feedback. You need to improve the feedback you get from your users, - but also you need to improve the feedback you get from your teams. And the feedback is something like, we need to refactor the thing. It's quite important to refactor the thing now, - not in three months, not in one year, no. Second, how we can move from inadvertent prudent to deliberate prudent. This is quite easy. Well, it's easy, I think. Because when a team is here, - in the prudent inadvertent, - they know more or less how to do stuff, - but they don't know exactly how to do it. So you need to let them make - some mistakes as a leader. You need to let them make some mistakes and - then ensuring that did not affect the morale of the team. Because if not, they will start doing the other thing. Like, okay, I don't care or something risky, - so I don't want to be in there. And two things that are important here, - like encourage the team to challenge business requests that compromise - technical solution. It's hard, - but sometimes we need to agree on how to do stuff and then, - okay, let's spend some time fixing that thing and then we will move forward - quicker with that other thing. And two things that I found a lot of times. First is avoid solution driving my individual efforts because one of the - pains of technical debt is when that technical debt was created by someone - that left the company. So you have no idea what happened there. So you will have to go to the code and try to guess what is happening - and how to fix it. And the last one is run away from over-engineering. Keep things simple. That will provide easily ways of changing stuff. And the last, how to move from the risky deliberate - to deliberate prudent. Mainly this is because the system, - the culture of the company. So mainly it's because there's a lot of work in - progress at the same time. There's a lot of pressure - from stakeholders, from product managers, product owners. So the first thing is to reduce that work in progress, - trying to maintain a good balance between the new staff - and maintenance. And be fair with that thing. It's not like, okay, that will take time for that reason. We made that decision in the past, - and then we now have to go in that direction. For sure, set a percentage of time dedicated to - cleaning or refactor 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 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 - that 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 dev, - 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.