5 Tips To Keep Technical Debt Under Control

Key Takeaways

[Music] if you're dutch you probably know what this is it's a coin you put into a shopping cart to unlock it you probably also have this in other countries it's also technical debt but before i explain why let's first take a walk so my office is back there pretty nice place isn't it so what is technical debt well optimally you want your software to have full code coverage use the latest and greatest libraries that are available 100 future proof so you never ever have to look at your code again well obviously that's not the reality the reality is when you create an application you often have to deal with deadlines and that means because of that deadline you won't be able to do things perfectly so you're going to use shortcuts in your programs to make sure things work but you know that you probably have to address them in the future that's an example of technical debt when you work at a startup you're also acutely aware of technical debt often you start building a brand new application using the latest and greatest tools and you kind of make fun of all those other companies that use old-fashioned crap but as time passes you become a company that also uses old-fashioned crap and you're going to need to do something to keep that under control why are these shopping cart coins technical debts in the past if you want to get a shopping cart you just grab one the problem was that people started to take these shopping carts home and use them for decoration for the kids to play in or i don't know what else for the issue is that these shopping carts are expensive they cost hundreds of euros to produce so the supermarket had a system where you had to put in a coin in order to use the shopping cart and that prevented people from taking those cards home for some reason i'm not sure what the psychology is behind it but apparently it works but nowadays people are using physical money less and less so people don't carry coins anymore so what was the solution well they introduced these plastic coins that you can get for free at the supermarket there's like a huge bowl of them and you just use that put it in a shopping cart and then you go shopping but that's weird because the whole idea of the system is that it dissuades people from taking those cards home because they want to get their money back and it's not like people think oh i have to get this card back because otherwise i won't get this worthless plastic coin back of which there is a whole freaking ball in the supermarket to do it right supermarkets need new shopping carts that use another system like detecting when shopping cart is outside of the range of the supermarket or something like that but that's expensive so they have this temporary cheap solution making these plastic coins is cheap but ultimately they're going to need to solve it and that's why it's an example of technical debt there are actually multiple types of technical debt i'll talk about that in a minute and i also have a few tips for you on how to manage technical debt and keep it under control at your company but before i do that i have to buy some food so i'm gonna use this and then i'll see you back at the office in a minute there are three main types of technical debt the first type of technical debt is deliberate technical debt when you're working as a software team you probably have some kind of deadline that you have to take into account and that means you can probably not do everything completely perfectly 100 the way that you like to do it so that means you're going to take some shortcuts that you know in the back of your mind you're going to have to take care of in the future that's deliberate technical debt especially if you're in a startup this is actually really important because development time in a startup in the beginning is much more expensive than later on because then you'll have the product out the door you have some customer so you have a bit more flexibility but in the beginning making mistakes is really costly so you want to reduce the time as much as possible that you release a piece of software get some feedback from your customers and adapt to it startups often immediately incur some kind of technical debt counterbalance to that is that a startup often also starts from scratch developing their code so they'll be using the latest and greatest libraries hopefully if they did their research what this also means is that any piece of software probably has some sort of technical debt you just can't get around it there's always something to improve the second type of technical debt is accidental or an outdated design so when you initially design your software you try to find a balance between future proofing your design and being able to quickly deliver something to the market but that means that probably when you deliver to the market the requirements are going to change you're going to learn new things about what your software needs to do and that means the design gets outdated other things that might happen is that you rely on libraries that get updated so now you have to update your software to use the new version of the library and so on and so on so if you designed your software well from the start you can probably get away with pretty small refactors to solve most of those problems but sometimes just have to bite the bullet and go for a more full-blown refactor because that's something fundamental that has to change in the way you designed this system but even if you created the perfect design in the beginning programming languages evolve and change all the time so that means you're going to have to change your code to keep up with that i mean look at how python has evolved over the last years lots of things have changed and that's going to impact the way that your software works libraries are going to get outdated best practices are going to change and you need to take that into account or otherwise you're going to end up with lots of compatibility issues and in my experience the older piece of software is the more this becomes a problem the third type of technical debt is rot and that's what's going to happen if you make lots and lots of small incremental changes to your code probably not even new maybe other people working on your team and those people might not understand completely the design of your system or how it was originally intended so you end up with layer upon layer upon layer you're losing efficiency things become less clear and start to be a bit messed up and rotten basically so that's bit rot so three types deliberate accidental and bit rot if you want to keep technical debt in check in your organization you need to actively manage it and i have five tips for you to help you do that the first tip is that you can greatly diminish technical debt in the beginning stage of software development by thinking about your design before you start coding away when you're at this thinking stage making changes is still easy so it's good to spend time there and take a methodical approach to coming up with your design to help you out with this i created a free guide that describes my process for doing it it's available at ariumcodes.com design guide it consists of seven steps that each take different aspects of your design into consideration i've tried to keep it short and to the point so you can take in the information quickly and apply it immediately to what you're working on so get it at ioncodes.com design guide the second tip is that it's really important to have a code review in place so that you can avoid in particular things like bitrot also define explicitly somewhere a set of standards and practices that you as a team adhere to and this is also very important you have to make the team as a whole responsible for the quality of the code not just the person who wrote that method that was badly written but it's the responsibility of the entire team to make sure that the code is of good quality and that ensures that everybody in your team takes these code reviews seriously the third tip is also really important and that is to make your technical debt explicit don't just think oh yeah we're gonna fix that at some point instead write it down as an actual task as a part of your sprint planning so for example you could add technical debt to your backlog as items so that you always know what they are that you're aware that they need to be done at some point in the future for example if you're using something like trello to manage your backlog add technical debt items there as well among the other regular things that you put in there doing this explicitly is a good thing because then every time you plan your sprint then you also see your technical debt items and you can decide to plan them in if there is some room and that's the fourth tip is that you should always leave some room in your sprint for dealing with technical debt that way you're spreading the work instead of that you have to suddenly spend an extraordinary amount of time solving technical debt and this often occurs at one of the most inconvenient moments because that's always how it goes so you can plan these technical debt items explicitly but you can also ask your developers if they see small things that are quick refactors to just do them and it's also close to what robert martin uncle bob calls the boy scout rule which is that you should leave code in a better state than that you found it so one more tip for you and then i have a little bonus so the fifth tip is to make sure that you prioritize and order technical debt items and also note any dependencies between them for example suppose you have a technical debt item that requires you to replace the database access layer but by doing that it also means you have to update the database itself and that might be a lot of work so it's good to be aware of that before you start working on technical debt items so bonus tip to avoid technical debt is to introduce metrics into your system of managing them there's of course basic things like code coverage when you're writing unit tests so you know if you have a very low code coverage percentage that you probably need to add more tests to your system to make it more robust but you can also do other things like count the number of technical debt cards and track their progress and if the number of technical debt items is way higher than the number of regular items perhaps you should spend some time on solving some of that technical debt you could even set some kind of alert that if you reach a certain percentage of technical debt items in your backlog that it automatically sends an alert that you should start taking care of this but also you can count the number of bugs or issues and make sure that this number never reaches a certain threshold to keep things manageable and then if you solve a bug also add a test to make sure that you're testing that the bug is actually solved and that if the bug ever reoccurs in the future then your test is going to point it out if you have any specific suggestions for dealing with technical debt please let me know in the comments below i'm curious to hear your thoughts now i'm gonna have to eat all this food that i just bought so wish me luck thanks for watching take care and see you next time you