Tech leads, project managers, and managers can prevent technical debt by giving software developers more time; in addition they can plan for spare time and refactoring sprints to allow teams to improve code, Nedelcho Nikolov claims. To prioritise technical debt, development teams can show how much time we can save if we invest now, and how complicated the software will become in the future if we don’t repay technical debt now.
Nedelcho Nikolov shared his experiences in dealing with technical debt at DEV Challenge Accepted 2023.
Technical debt is often caused by a deadline that you have to meet, where you have to rush the code and you don’t have the time to do it properly, Nikolov said. You have to compromise things, and usually those are either the unit tests or some badly written code on production that just works and no one knows how and why, he added.
Another cause of technical debt might be that the team is still new and there are still no coding standards in place, as Nikolov explained:
We had a newly formed team working on a brand new project, so everyone was writing the code in his own style, which made it hard to maintain and to find something later on.
Tech leads, project managers, and managers can prevent technical debt by giving developers more time to test everything and write good code, Nikolov said. They can also plan for spare time in the project so that it can be spent putting things in order after the big rush, or just allow the team to have a couple of refactoring sprints so they can take time to improve code.
Prioritizing technical debt is difficult because you have to convince the people above you to spare time for something that will not bring money to the table, Nikolov argued. He suggested putting some numbers into the conversation, like how much time you can save later on if you invest it now, and how much more complicated it will become in the future:
This can be shown with estimates from the developers if the code was written ok and there were no debts, and as the code is in the current condition. Usually, stakeholders are interested in numbers, so this might be the best approach.
To deal with the technical debt, Nikolov suggested that teams invest time each sprint to repay the debt, or at least when team members do their task and see something that is left in the pipeline for fixing or refactoring. This is an easy one to do: just invest the time now and do it, he suggested.
Another approach involves dedicated whole sprints just to fixing, as Nikolov explained:
We had one project with a new team working on it, which finished on time with compromises in the code quality. After we were done we dedicated a few sprints to refactoring everything and putting it back in order. This way we managed to repay our debt and we had a nice-looking codebase that was easy to navigate and to add new features to.
Dedicate time whenever you can to pay your debts, as with time it gets harder and harder, Nikolov added. Don’t be afraid of technical debt; it’s a needed evil. It allows us to finish a project or task on time, but we must repay it as soon as possible afterward so that we don’t end up in a total mess, he concluded.
InfoQ interviewed Nedelcho Nikolov about dealing with technical debt.
InfoQ: If we can’t make detailed estimates on the costs and benefits of repairing technical debt, is there another way to prioritize it?
Nedelcho Nikolov: Another good approach is to use an effort/impact matrix, in which you can score every task in the following ways:
- Easy to do and it has big impact on the work - Quick win
- Easy to do but it’s not going to help a lot, as it’s in a part of the code that is not changing, or it’s a feature that no one is going to change in the near future - Time fill-ins
- Hard to do / It’s gonna take more time, but it will have a big impact - Major Project
- Hard to do and no impact on the project - Money pit
With the scores above in mind, you can easily prioritize which debt you should repay now, and which can wait.
InfoQ: What can we do if there’s a lot of technical debt accumulated over time?
Nikolov: When you have accumulated so much technical debt that it’s really hard to deal with, that’s the point at which you just have to start the whole project from the beginning again. It’s hard, but not impossible, to convince the stakeholders to do so, as you want to spend time not bringing in money or adding new features, but instead, redo something that is already there.
We encountered such a project with my team; a 15-year-old PHP application lacking any framework, featuring mixed PHP, HTML and JS code all in one file. The stakeholders wanted a complete redesign with responsive design. With some proper explanation and some estimates, we managed to convince them to start the whole project from scratch. Now we have a modern PHP application running on Laravel with VueJS frontend, partnering with Tailwind CSS. Of course, we now have new technical debt to repay because of the timeframe that we had, but slowly we are repaying this debt every sprint.
