 So welcome to the session about managing technical debt. So I am Nils, I'm from Belgium, this is Dieter, he's also from Belgium. As you can see we are not the best at posing for our company pictures. Between us we have a good 29 years of experience with Drupal and it starts to feel like we're the old guys at the office like starting to wave our finger like watch out if you do this or that. One of the things that I want to also mention is that Drupal here is at Drupal con Lill. So visit our booth, get a waffle, you've probably smelled it already when you entered. If you don't like waffles, I'm sorry for the smell. If you like it, enjoy and have one. So I like to think about that first Drupal project I ever made. It was actually a website for a local hotel from my hometown in Ostend. That was in 2005, so it was still Drupal 6. And I would like you to also think about that first Drupal project you ever made and just have a real good thought about it and think about, you would probably be very proud when you made that first one. It was a challenge. We all know that the learning curve of Drupal with the hangman at the top of the cliff and you were right to be proud of what you made. But probably just like me, it might have been a bit different. So raise your hand please if you would do it differently now. Exactly how many people I thought were going to raise their hands. So this is also the reason why you're probably here for this session is how to manage that technical debt that accrues when you first make something and after a while it starts to stack. So my first project I perceived a bit like this. A nice house, lots of features, very nice. It just felt nice. But actually what I built was more akin to this. So something that looked a bit off when you look at it again. It had all those features but still it wasn't good enough. So usually what you do with these kind of projects is that you have two options. So either you start from scratch. In the past we had a new Drupal version and then we could build the site again and that was like kind of an excuse to actually build it again. Now with Drupal 8 and beyond. It basically means we have to do better. That means we need to fix more and we need to keep that code alive because these sites just live longer now. So I was very lucky at the company that I worked for that we actually had clients that allowed us to fix the initial, I'm not going to say mess but you all know, that we made to actually make it better and make it evolve through the years. So today we're going to talk about, so what is technical debt? What does it mean? How do you keep track of it? Also how to engage clients because there's always budget linked to it as well. And then switching from contrip to core modules and then automation and prevention and then we'll end with some questions. So what is technical debt? I think a lot of you already know and I just wanted to recap it to make sure we're on the same page. We all have the same basic definition in our head when we talk about it. So what you do when you want a definition, you go to the internet and you Google it or use chat GPT. And this was quite a nice definition that I found. It's the implied costs of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time. It's quite a nice definition in my mind. It covers the basis quite nicely. It can explain it quite nicely. But to go a bit more in depth and to give you some tools to explain it to your clients because your clients will most likely not be developers and won't necessarily understand the definition. You can start by explaining that software is like an iceberg. Most of the code that is being used is not visual. I think all of you will have written integrations with APIs, migrations. A lot of things that are hidden below the surface are there and are absolutely essential to the functioning of the site. How many of you have gotten a remark from a client that is something like ah, but I've made a site in WordPress or I can do this in Wix? Why can't we not do that with the site that you made? How many? Can you raise your hands? All right, that's quite a big group as well. So that's something important that you explain to clients as well. That software is not just something that you use on the internet. There's a lot below that that needs to function correctly and that's usually where technical debt will occur as well and the hidden party iceberg beneath the surface. We also added some metaphors that could help you explain it to clients as well. So technical debt you can compare it to financial debt and you're borrowing against the future. You're basically choosing something suboptimal for now that will fit within the current budget but it will give you problems in the long run and you will have to pay that debt off somehow. It is not necessarily a bad thing. That's also important. It can be a good thing to choose a suboptimal solution now just so you can deliver the project or you can get to a certain deadline but it is something that will accumulate that over time. Weeds in a garden. If you have software and you don't maintain it, it's like weeds in a garden. You need to maintain your garden or your actual plans that you want will wither and die. A house of cards. Basically every time that you have a... I used mid-journey to generate images to try it out as well so they're quite a bit weird sometimes. Technical debt is like building a house of cards and each card represents a shortcut or a compromise that you made during development. Every time you do that you add to your house of cards and the bigger your house of cards is, the easier it is to trip it and make it fall down and just obliterate everything that you did. Where does technical debt come from? So there's quite a long list of things that can lead to technical debt. We try to group them into several categories. So in like the meta categories, it's all things that are to do with, for example, project planning, resources, skill level of people working on it. If you have tight deadlines, if you need to do hasty fixes because of that, you have resource constraints because you don't have enough development capacity to actually work on it. You don't have documentation for the things that you're building. So developers work on top of things that they don't fully understand. Technical skill gaps because your developers are not experienced enough, they need to write a migration and they've just gotten out of graduate school, for example, that is not gonna lead to good results. In adequate communication, in adequate communication is also a big one when developers do not talk to each other and just work in parallel without communicating about how things need to work together. Requirements of that change. I think, again, many of you had a project being started and then after two weeks, the client changed their mind. I see people raising their hands for ask the question. Yeah. I think that's a big one that you need to also inform clients very proactively about. If you do that, if you change your mind, it is gonna be harder to stay within budget. It's gonna be harder to deliver the project on time and we will potentially have technical debt that can lead to problems. And scope review. Same basic problem. Your client just wants more for the same amount of money. I'm not even gonna ask for the people to raise their hands. I think that's something that happens in every project. Then architecture and design. I think that's also a very important one. For bigger projects, definitely, you really want to think about how your code will be structured, how you will organize everything. If you don't think about it beforehand, you usually have an inflexible architecture that is very resistant to change, where it becomes harder and more costly to make changes to the further one in your project you are. The same applies for short-sighted design decisions and design you can basically take as software design and actual front-end design as well. If you only focus on your immediate needs without thinking what will happen in the long run for the projects that will live years, maybe even decades, I think we can start saying by now, then you will have a problem. On the other hand, and I've seen that happen, over-engineering can also lead to technical debt. If you need to make an integration with an external API, and you start making a generic integration that can integrate pretty much any API because when you want to add pieces of code, then your code will be very hard to understand and maintain as well. And then that is also a form of technical debt. If a new developer comes in and he needs a date to understand the code that you wrote and the structure, you're not doing the optimal job. Complex workarounds and inadequate security measures are just two ones that fit broadly into the same category. If you ignore those, they will also lead to technical debts. These are the ones that might be the most interesting for the group that's here because I'm presuming that most of you are developers. Poor code quality is, but can also lead to more technical debt. So don't underestimate just pushing things through because you want to get things done what that can lead to. Lack of code review ties into that. We're applying that and it really helps to detect issues in structure of code very early on. Preventing partly technical debt. Inconsistent code style. Very easy to prevent. We'll get back to that at the end. But if you don't have consistent code style, your code becomes less readable and again you will have problems with technical debt. The code smells ties into that. Legacy code. We have a project that we'll get into later that have been running for seven or eight years already. They were started in Drupal 8 Beta. That is partially legacy code but if you don't maintain that, you don't update it properly. It again works against you instead of for you. Lack of version control. Lack of automation and adequate testing. They all tie into things that you can do very easily to make sure you prevent technical debt. And the last slide with the causes, then I'm done. Outdated technologies. Frontend developments. You work on nodes. You're doing it on version 14 right now. You don't maintain it. You don't need to do it anymore. You need to maintain that code. Otherwise you won't be able to do bug fixes and corporate patches. Lack of refactoring. Dependency hell. Ignoring technical debt will only lead to more. And framework or language changes as well. A shorthand definition that we kind of use a bit when we talk about it is every suboptimal solution that you choose in your code base, in your documentation, most likely you are generating or accruing technical debt. And every time that you're working and you're developing and you think this code is working against me and not with me or for me, probably it's technical debt that you need to take a look at and see if you want to refactor the piece of code to make sure that it will not have the problem in the future. Before we go to the next slide, I'm just curious, are there any other definitions or shorthands that people here use that you think are interesting to share? Yeah, we're making a bit interactive, so... Okay. If you have one that you think about at the end, you can still feel free to share it through the Q&A. So, keeping track of technical debt. That's the most interesting thing, I think. It's all fine and then you need to know where it comes from and what it is. But if you don't know about it, it just stays hidden. So you want to make it visual. So this is one of our colleagues. This is Walter. We have posted notes, but it is a handy tool for modern people. There are more modern solutions, so you can use issues in your issue tracker. You can use posted notes. You can use cards in a board in whatever tool you use like Trello. It doesn't really matter. We use the issue tracker mostly because then it ties in with our development process and maintenance process. And you just tag them, categorize them, or do something to label them. What is important is try to make sure you already give it an order of magnitude and an order of impact if you fix it. You can have something that will take 100 hours to fix, but the impact is going to be basically almost nothing. You can have something that will take 2 hours to fix and the impact is going to be very big. If you write that down, you can easily generate a list from it and just look at that list and see what are we going to tackle and tack it on with change requests to make sure that you fix it. And then the second one that we think is an easy one to use is putting it inside your code using comments and annotation. And that is already something that happens in Drupal Core. Whenever there's a minor update, whenever things are added, things are marked as deprecated. The things that are deprecated that you're still using is technical debt. So that's what you want to fix. So you can use that as a tool as well. Ideally, use a combination of both. So when developers are working on code, they can see it very easily that they're working against something that is marked as deprecated or that should no longer be used or should be refactored. But you also want to have that list in an issue tracker or somewhere else so you can visualize it for the project manager, for the client and for yourself as well to see what is going on. Then engaging clients. Give the word back to Nils. So now that you kind of know what is technical debt and how to identify it in your project, it's actually time to convince your clients that something needs to be done about that. So in many cases that I've had while I'm trying to convince my clients is basically they say, it's not broken. Why bother? Why do we need that? But I think we are in a unique position to actually explain the value of why we need to do that. So I want to give you some tips on how I do it. So I have a couple of pillars that I like to use when I'm thinking about those technical debt issues what I think about, okay will this improve one of these pillars? So for instance one of the pillar I use is developer experience. Imagine if your developer is faster because there's less technical debt maybe less developer burnout it will be at a benefit to your clients as well. For instance for UX usually if the UX is better, the user experience is better it will lead to more conversions and then also possibly more income for your client. The editor experience again same thing. If the people who are actually putting in the content spend less time on putting in the content that means there's a profit somewhere. Performance faster site usually you know that leads to better SEO possibly better conversions and then more income again. So it's always like a cause and effect thing that we're going on. Performance I mean security security usually comes down to preventing possible costs that you might have when there's a breach. Then stability again if you have a site that's down that's going to cost the client even more. So if you can improve the stability make it sure it's always available it will have direct impact on their bottom line. And then the last thing is maintenance. The cost of maintenance how much does it cost if you can lower that that means every year is just cheaper for them to keep their site alive. So I had some examples that I wanted to show you. The first one is we had a project that after a couple of years the database was growing very very large because we were using revisions and paragraphs and all of that and there were a lot of content changes and in the end it became very big and when developers had to work on it it was sometimes a hassle for people to get down an up to date database so we saw that as something that was actually slowing us down a lot so our solution was to reduce the size of that database so our developers would spend less time fixing bugs or creating new features the other site was also then the lower maintenance cost because those backups that we take every day were also a lot smaller so that means that it was a direct win for the client so when we explained that to them it was clear why we needed to reduce the size of the database another thing was on that project that we talked about is where we want to do the switch for workbench moderation to content moderation I don't know if everybody knows about that module but content moderation is now in core as well so it basically allows you to change the put a workflow for editing your content so have a draft published version so you can do all that so in the beginning there was workbench moderation that allowed you to do that now it's in core so doing the switch from that could potentially lead to lower maintenance cost because as you might know that it could be that in the future workbench moderation is no longer supported so that means you might get like if it's no longer supported then and you want to upgrade your version then you might get stuck so it's important to switch out to that core version then so you're not blocked on that the other thing was another project that we had was actually a big product site that had an API a product management system that we were syncing the content between so every night we were getting all the latest products and all the updates from that API so at first we just built a straight connection between the site and that API but it was not stable at all their API so in the end the consequence of that was that actually our developers were getting stressed because they weren't sure if it was going to break or not and it was a very complicated migration and it was written with a lot of dependencies in it so it was not easy to roll back so it was just causing stress for developers and also stress for the client because sometimes they were not products were not updated correctly or they would even lose most of their products on the website so then we actually proposed them to put an intermediary solution in there that allowed us to have that stability and then our developers slept a lot better and we moved on from there then maybe the simplest one example of all is unused elements I don't know if you also had that where you look at your site and then you see some content types that have a field and nobody knows what it does you're looking at it and you want to build something new and you're trying to think like okay what does this do did we write it down correctly it just costs you time to figure out to make sure that if you build something new that you take that functionality into account so if it's not used, remove it it's a simple thing if you're not using it, remove it and that will indeed then again go into the editor experience as well the editors will not be wondering every time when they fill out content do I have to fill it in or not it won't cause any confusion anymore same for developers it will be easier to estimate new things new work and they will be faster at developing it sometimes just saying those things to your client is not enough so sometimes it's good to calculate a return on investment together with them so help build a business case with them so try to get some figures from them like I have some example figures here like visitors per month full time equivalent of editors per year how much time do your editors spend if you get a bit of those simple business data you can actually use it to make a business case so I brought an example this is not something that is for one of our sites so for instance many of our sites used to only use paragraphs our new sites now only use layout builder to build so now we have some clients that say like oh we also want layout builder and then we want to see like okay what is the cost for actually moving from paragraphs to layout builder and is it worth the investment right now so today we made a simple calculation so for instance we have calculated that for a website it will cost us 60,000 euros to actually switch it from paragraphs to layout builder and make it fully work and fully tested if we look at what benefit layout builder brings us you could look at the case of the editor experience for instance in this case we calculated that okay if they use layout builder it will be about 5% faster so if they don't have their time could be spend doing something else based on their wage we make a calculation and then we say like okay so clearly if we switch that will bring us 6.7k per year so if you compare it to that 60k that will cost us then you clearly see like it would take us 9 years to actually get that paid back so that return investment that would be I did not bring it to the client because it was not worth it it didn't make any sense to me so we dropped it and we'll see in the future but I have an alternative history whatever scenario in my head where imagine and this is not the case but imagine in the future paragraphs is no longer supported imagine nobody uses it anymore it doesn't get any more support and it stops at that moment at a certain point imagine Drupal version 20 where paragraphs is not supported but you want to upgrade to version 20 but you can't so that means you would be stuck in the latest version Drupal 19 forever so you would have to make that move so either you choose then to rebuild the site rebuild it using the latest technology and features and then change it so in this case it's an easier calculation to make because if you have to rebuild the website it might cost you 150K versus that 60,000 euros that you were going to invest so that means if they need to spend that budget of 150 then if we just change it, if we upgrade it then that means they would have 90,000 euros left that they can spend on other stuff and then we can have new features that will bring them maybe more income there's one caveat there though and we stepped into that one very hard and it was very painful is that we went too hard on the technical improvements and we didn't explain it enough to the client and we did not think about enough about the value of new features so in 2006 because the new features usually help with the other stakeholders to keep them convinced that they need to keep on doing these things and then combine it with those technical debt issues so one of those big things is actually switching from contract to core so in 2006 when we started with Drupal 8 then the client needs were actually the same as they were now we did not have the contributed modules yet stuff was not in core many of those for instance for me was like Workbench Moderation was one of those for sure another good example is the media module so we started out many of our projects using file entity because it was the right way to do we thought but in the end we that accrued us some technical debt so we did not have any of those for projects we did do a switch to media fully so these are a couple of examples that also have gone into core now from contrip that's panels and penalizer going into layout builder and then json api from the contributed space into the core space then maybe the less obvious one was the one I mentioned already it depends on your scenario it is not a direct inclusion so again here why would you move one of your functionalities from that used to be contributed code into core it's because you might miss out on new functionality that might be easily given to your client because new people might make new modules that are only against the core version of it and no longer the contributed version and then again the case of what if it's no longer supported that at a certain point you'll get stuck upgrading your Drupal and then you'll run into that security issue we're all in the same boat I think so it has inspired some contributors to provide a migration path between these so for instance file to media workbench moderation to content moderation so it's important to also keep those modules alive and help people to make them move will this ever stop? I'm not a prophet but I hope not because I think much of that innovation actually comes from the contributed space I think there are great initiatives there the one thing is the asterisk I have there is please help out your early adopters tested the modules that were created and help them move on to a stable version and avoid the technical debt and I'll leave it to Dieter to tell you about the automation and prevention so some stuff you can do we're not going to go into too much details because there are dedicated sessions that go into way more depth for specific tools you can do some automation and prevention of technical debt fairly easily so what are the benefits of doing that? I need to look at the slides because I cannot read the text here so small if you automate the checks you're going to reduce the time spent on maintaining your code so a code review process is something that you should have for anything you do in my opinion but if you automate some part of that you're just going to reduce the time spent in your code reviews you're going to reduce the time spent for your developers to check it and you're also going to increase the level of your developers because they're going to get automatically feedback on the code that they make you're preventing bad code quality by doing that it will enforce coding standards decent code division it will enforce a better architecture for some tools increase your consistency in the code so it will not be that developer A wrote something developer B wrote something that will be completely different it will be more in line with each other making it easier for new people to jump into the projects and it will increase your developer skills like I said it's just automatic feedback that you get from your developers here are some examples I think all of them are using Drupal core so if you use code sniffer it enforces the coding standards from Drupal you should use it on all your projects for all the custom code that you write it's encouraged for contract modules as well to do that to keep everything consistent mesotector is very handy you need to really change the parameters out of the box because out of the box for example it only allows you three arguments per method but it will help you make sure that you don't have files that are a thousand lines long you won't have methods that are 500 lines long it will help you to divide your code better and make sure it's more easily maintainable PHP unit for unit testing of course if you want your project to live long and you don't want to have mistakes popping up after the fact by clients reporting it you do want to have some automatic tests and same applies for the tools on the bottom PHP stand is one of the most useful ones that we started introducing a while ago for all of you if you want more about PHP stand look at Matt Glayman's sessions and so on he has a lot of more information about it but it helps you tremendously in figuring out where your code could go wrong or where issues could arise you're developing against an interface that doesn't have a method but you're still using that method then it's going to give you notification you have if statements that will return a true for every single case because of the way your code is used it will give you that notification there's a lot of things that come out of it that really help to make the code better and structure it better so those are the tools I just put the logos here look into them if you don't have them look at Drupal core because most of them are in there with a GitLab CI file and it's very easy to adopt it in your own projects so that is the end of the session we have some time for questions of course more than enough time even I think don't forget on Friday there's contribution day so please go there you can learn more about technical debt by working on some bugs in Drupal core or refactoring some quotes it's a very good way to learn about why some things need to be done differently and that was it thank you all for your time and joining us for this session so we have one question or comment more it's from YumB I know it was just an example figure but how would you actually calculate that LB versus paragraphs would mean 5% quicker page edits not say 30% that would make or break the business case very good remark I must say I like to take the lower end of those estimations usually because either you actually try and figure it out you do the tests and you figure out like okay this is actually a good number otherwise I try to tend to stay on the low end of it is that an answer to your question any more questions people that want to ask a question so feel free okay we have another one from John K how do you manage the desire to be agile develop MVPs against how to avoid hexagonal debt I think then a lot of that question comes from misunderstanding on how agile works it doesn't just mean go with the flow you still need to do some form of planning and look towards the future it is not the coming two weeks we will work on this in agile you also have a backlog of items that you prepare for weeks or even months into the future but you just change what you actually work on so you can still prevent technical debt in the same way your methodology does not really impact it that much it's the same basic principles you're gonna have technical debt at some point because you need to make decisions to do something quicker or to have something done by a certain date or because you make certain decisions that bite you in the ass a couple years later they need to refactor you need to put that on the table so in fact I think even agile can help you with that because it's very easier to raise concerns quicker and talk with the client and make a mix of technical debt and project features by just instilling the importance of fixing it versus a waterfall project where you basically define your scope at the beginning and you work on it where you can only start talking about it at the end or on upsells later on the basic principle again is communication with your clients convincing them and keeping track of it if you do those things working agile, working waterfall, any other methodology it doesn't really matter that much does that answer the question yes no, it's mostly sorry, yeah so the question was if we have dedicated people looking into technical debt for older projects to find it out no, because if technical debt is there and you don't need to touch the code and everything works then it's not that important, your return for fixing it is too low to actually do it it's mainly when you encounter items where you need to develop something and you encounter the problems you see problems when you're actually changing features or adding features that's when you look into the technical debt and actually fix it, if you start doing it proactively you're just gonna most likely waste budget anyway, now we you do of course the updates for Drupal every half year and then major updates so people are touching the code and those are usually the moments when technical debt is encountered and can be locked so with Drupal and the maintenance that they have and that's how modern Drupal helps you a bit and you have every half year need to do an update or you should do an update, you don't have to but you should, then you're gonna have the opportunity to look into the code and fix items find problems and then you can decide to fix them then you can log them to fix them later and you can talk about it with the client does that answer the question? okay yeah, I think very much so if you cannot get a patch incorporated in a contract module or in core and you need to continuously rewrite it which happens for contract patches but also for custom patches that are dedicated for a project that's definitely technical debt and you can fix that in two ways you can either keep rewriting the patch in a way to enhance the code of contract or change it without needing a patch so you can write a patch for a code or you can write, for example, a decorator in a custom class and then it's no longer that form of technical debt okay, does that answer, okay I was mainly looking to the left does anybody else have any questions? there's any more? no alright, then I think we're done class dismissed, thank you very much for coming have a great day