 So hello everyone, my name is Matheus, I'm a senior software engineer at Red Hat. Times of the assets, I'll be able to address any Q&A by the future to reach out to me afterwards. I'll be happy to answer questions. And today I'm going to show you some ways you can manage technical depth in your teams and projects. So technical depth is akin to broken windows in a building. If you leave a visible broken windows and a repair, other things will eventually be broken, leading up to misdemeanors, disorderly conduct, and general disarray. This criminal slip or slope is the broken windows theory. And it's an actual thing in criminology. The pragmatic programmer compares it with technical depth, telling us that a code-based riddle with technical depth is a lot like a building with broken windows. But I personally feel like technical depth is a lot like doing house chores. Have you ever let dirty dishes stack? All it takes is a single day without dishwashing. Then in the next day, you see that overwhelming pile of dirty dishes, glasses, silverware, and then you might feel tempted to just grab a clean one and have my next meal with it. And I'll wash the dirty ones later. And then just like that, the stack will keep growing and growing and growing until you run out of dishes, until you run out of silverware, until you run off glasses, and either you wash them or you face a starvation. So a very similar thing happens with code. It can all begin with a single unoptimized function that gets left behind, like this bubble sort here. Or even some dirt that could be refactored. But the main issue here is that bad code has gravity, as it tends to attract even more bad code. And after a while, the application's code base becomes such a mess that simple changes can take weeks to be deployed. Who has been in that situation before? More people that I don't like to see, which is unfortunate, but it's the life of software engineering. And this impacted your quality of life, right? Who felt bad? But not only quality of engineering gets affected, the business itself gets impacted by that because you need to quickly deliver in order to achieve your business goals. A Gartner report tells us that actively managing technical debt leads to a 50% reduction in delivery time. So I guess we have plenty of good reasons to keep technical debt in check, right? So you might be wondering, how do we do it? We first need to define what technical debt is. And believe me or not, the semantics actually matter here. Some people argue against the term itself, citing that it can be deceiving. Some eccentrics even advocate that you should stick a banana peel to attack debt tickets in order to force you to address it as soon as possible. The reasoning being that nobody wants a dirty working environment, right? But the important message here is that each team needs to define what constitutes technical debt for them. And the usual suspects are, how can I point this? Okay, usually non-blocker edge case and work-aroundable bugs, code refactors, non-blocking infrastructure work, such as CICD improvements, database turning or infrastructure turning, some optimization, in general, low priority and un-urgent improvements. So nothing that's urgent, like one or two dirty dishes on the sink, but if they keep stacking, we'll only hinder you on the long-term. And also notice that all technical debts falls into two types, intentional and unintentional. Unintentional ones are usually related to bugs or can be related to oversized original design, shortcomings in architecture. Unintentional ones, however, have multiple causes, such as the need to meet a deadline or to quickly prototype something that can be optimized later. And this classification might help you or your organization with your technical debt definition. But please, don't take this as a set of rules. This is also not a comprehensive guideline of what technical debt is. Think totally about your team's context, domain and scope and try to figure out what technical debt means for you. And different teams might require different definitions. We have now discussed the periods of technical debt and how to define it. So how do we keep track of it? Your best bet is to use the same tooling that team already uses. So if you're using JIRA, stick to JIRA, if you use Trello, stick to Trello, if you use a physical Kanban board with six nodes, keep doing that, no reason to reinvent a wheel here. However, it is good practice to regularly reveal the tech debt you have in your backlog. You should evaluate whether it still makes sense to deal with and drop anything that no longer makes sense. See the opportunity to refine whatever still needs to be solved, however. And now we explore the basics of technical debt tracking, definition and why you should deal with it. But you're probably wondering now, how do we actually manage it and keep it in check? We have to approach this with both strategy and tactics. And while the tactics vary, my experience shows me that there is all but one strategy to effectively get technical debt under control. Can anybody guess it? You need to foster a culture of continuous improvement in your team. Everyone needs to be committed on improving the code base, not letting technical debt slip. Engineers love and clean well-maintained code base. Who here likes to code on good code? On a clean architecture, on clean code. Look how many hands are raised. So it's natural. And they will make the effort to keep the code clean. This is literally the broken windows theory. If your house is well-maintained, you keep it well-maintained. If a code base is well-maintained, if it's cleaned, it has a clean architecture, engineers will strive and make efforts to keep it that way. And it pays itself compounded over time. And in order to achieve this, a team needs to be enabled and empowered. A team needs to really own their systems and services and to end and be proficient at their tools. And management buying is also critical. Even though there's a good strategy to handle technical debt, the actual tactics for dealing with it vary and it depends on several factors, such as team size, context, delivery process, sometimes even on the tech stack itself. So it really depends on how to actually do the tactics, but there are a few mainstream ones. Some teams go by the golden rule, which dictates that each sprint has 20% reserve capacity to address technical debt. And some teams even split 20% between actual bug fixing and other technical debt issues. This has the collateral benefit of, by default, creating the technical debt management habit in the team. Does anyone here follow a similar approach in their teams? Okay, a couple of people. It's nice. Other teams deal with technical debt as regular issues and has the team stack leads or architecture act as their stakeholder or advocate for the tech debt. And this can lead to some sprints having no technical debt in them, but other ones might be technical debt heavy. But again, this is no set of rules. Just a couple of examples from the industry. My suggestion is for you to experiment with them and stick to whatever you feel it works. Also, it's worth noting that not all technical debt is bad. Sometimes it is okay to accept some technical debt, especially if you are resource pressured. And resource here can mean money, time, even manpower. Sometimes you might need to quickly hack an MVP in order to beat the competition and be the first to go to market. And sometimes you might need to accept a sub-ultimal infrastructure if you're operating under a constrained budget. In this case, technical debt might compare to actual financial debt. Think as those intentional debts as the equivalent on taking a loan to start a business. In other words, not all debt is bad by default. What really matters here is your ability to pay it back later. Keep that on your mind. But the main thing away here is to not distract what really matters, which is to embrace a continuous improvement culture and for the team to be the main advocate for excellence and quality in their own code base. But let's now explore a few cases and examples of technical debt being managed in practice. Let's first explore how to manage a legacy application of technical debt. You don't need to be a wizard to do that, by the way. It is an application that is already in production and therefore has concerns such as uptime, SLA, not introducing new bugs, not introducing new bugs, and most importantly, not breaking production. Does anyone here maintain a legacy application? Yeah, good luck. But also there are two sides of being a legacy application maintainer. It can be hard to change. Deployments might be complex and overall introducing new features or fixes to the application might be difficult. However, on the other hand, and this is a pretty much an upside of being a legacy application developer, you know what's going on. You know it's shortcomings. You know that it might be missing automated tests. You know that it's CI CD might be unoptimized or it might have a couple of megazord classes that you could break down into smaller classes. In other words, your technical debt is already mapped for you. For example, if this is a monolith that is hard to scale or it's hard to deploy, we might want to explore a strangler pattern and plan to break it down into more maintainable microservices. If it lacks automated testing, we can create a policy that any new code must always come with their unit tests. Also file tickets to implement tests for classes or module that might be missing them. We can even wrap it in a container image so it becomes easier to deploy it on public cloud fully averaging CI CD capabilities. All of those things are tactics and techniques and while they still may vary, depends really on the legacy application, the other strategy is still of implementing a continuous improvement culture on the team. This might be easier said than done. Okay, I don't say it lightly. Especially if the project has been neglected for a while but start with some small steps and keep improving things until we get technical depth under control at least so that it doesn't run wild. The upside is that those small but steady improvements eventually compound with each other, improving overall developer experience. And this will engage everyone to keep tackling technical depth and we continuously improve the code base. And my personal experience leads to believe that a golden rule approach might work best for legacy applications because there are always going to be bugs, improvements that you need to address and it's worth it to always account for that in sprint capacity. But yet again, your mileage may vary and analyze what works best for you and your team except critical thinking. But now what if my application is something completely new? You have then a great opportunity to get things right from the start. You begin with no previously existing technical depth and it's entirely up to you to get it right during the development cycle. There's a challenge in identifying it properly and documenting it so the team doesn't lose track. So don't forget to file the proper Gira tickets. And also there's no excuse for you to not code unit tests, okay? It's new code, you should be doing tests. Automated tests help you with regressions, refactors and overall engineering metal health so there's no excuse to not have them. But the actual main challenge here is to get management, sponsorship and buy-in to properly deal with technical depth. Especially when we might be in a situation where a hard deadline for a launch or firstly release exists. What might help you here is to show that not getting technical depth under control on the short term might lead to some bigger technical issues in the future which might hinder the overall product development. In this case, I strongly recommend to have the tech lead or project lead to act as technical depth advocate and argue them with the manager or stakeholders so that this can get prioritized at least for, let's say, the first post MVP release. Yet again, the main challenge is to foster continuous improvement culture and to get it right from the start. And those tips and examples here are to make you think about how you've been doing things to fight technical depth on your team and company. But this isn't a cookie cutter solution so I exert critical thinking and try to figure out what works best for you. My experiences didn't believe that fostering a continuous improvement culture is the best bet but there might be other solutions out there. But regardless of strategy or tactics always remember that it takes a single broken window to rec buting. Don't let your guard down, fix your broken windows. Thank you.