Technical debts are probably one of the greatest frustrations and demotivators for a software development team. They are unavoidable and no matter how hard you try to avoid them it will somehow find a way into the codebase. The problem with technical debt is that oftentimes the business just keeps wanting to add more features and that’s it. Eventually, the technical debts pile up more and more and it feels like you’re building a leaning tower. The foundation is deteriorating from technical debt and you’re just trying to add on top of that.
In this post, I want to go over 4 ways to address technical debts by bringing understanding to both the technical and business side.
1. Have Technical Debts as Part of the Iteration
Most software development team works under agile methodology where they have an iteration with target goals by end of it. Include technical debts into an iteration so they will get work on. After all, what is in the iteration is what the development team has committed to deliver. So, if technical debts are part of it then they will get time to be worked on.
There is no magic formula for how much features and technical debts is part of an iteration. However, it seems to be common to have a 70-30 or 80-20 split, where the technical debt is the lower amount.
2. Make Technical Debts Visible
You don’t want technical debts to be not visible. If it is not visible then others are not aware of it — out of sight out of mind. Even other software developers on the same project might not be aware when a project is large enough. So, it becomes important that the technical debts are visible.
You can make technical debts visible by treating it as another item in the product backlog. That way everyone can see them. It is important that everyone is aware of the impact the technical debts have. Then as a team decide on which ones to work on.
3. Explain the Impact of Technical Debts
Don’t just say the code is bad or some code should be improved. That’s not going to convince any of the non-technical people of your project. In most cases, they are the stakeholders and wouldn’t understand the need to address technical debts if that’s the kind of reason you provide.
Instead, explain technical debt in some other way that is more understandable. For example, you can explain how technical debt is like taking a loan with interest. The longer the loan is not paid off the bigger the interest. Eventually, all you’ll be doing is paying down the interest.
4. Identify the Technical Debts
As simple as identifying the technical debts might seem it is a critical one. Until the technical debts are clearly identified you can’t address them.
Also, when you start diving deeper you start to get a better picture of how severe the impact might be. One of the problems with technical debt is that it is usually not isolated. It has a domino effect across the code.
Handling technical debt is like a balancing act. Achieving business agility by only pumping out new features is unrealistic. At the same time, an application that is perfect from a technical perspective would not have much value without customers. The two sides need to meet somewhere in the middle to consistently provide a valuable product to customers.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
To get in touch, follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.