What is Tech Debt?
Technical debt is a set of decisions that were made in the past, that you want to change now. These decisions can be related to architecture, software design, infrastructure or even some of the code you wrote. You may have made them intentionally decide to deal with consequences later. We've all been in a situation when we need to get something out of the door quickly but then come back later to fix it. Or it may have happened unintentionally, for example out of lack of knowledge in a new area or lack of experience with a specific subject.
One of the other aspects of scaling that companies run into is technical debt. When companies grow, in addition to organizational challenges they face technical ones too. Technical challenges come in different shapes and forms, like issues with scalability, aging infrastructure, and stuff like that.
Accumulating technical debt is very dangerous because over time it tends to have a negative effect on a team - slower change cycles, changes that are harder to make, fragile areas of the code, etc. This leads to the situation that the estimates are being gradually increased and noticeably fewer tasks are performed during the sprint.
How to deal with technical debt?
There are two different ways to pay off technical debt:
1. As part of regular roadmap work
For example, when working on the MVP of the Order Management System we've decided to cut some corners. As soon as you plan to work on tech debt items you incorporate this work as part of the upcoming areas or milestones of work. But then come back later when doing the next chunk of work related to this area.
2. As a separate initiative
For example, if you see there's an area of the code that developers are trying to avoid touching or afraid to change at all - to me that's a big red sign of tech debt. However, even if there's no item on the roadmap associated with that area it may still be well worth the investment to improve that piece. So that it's easy to make the change when you need it. And you don't have developers that are afraid to touch it.
In either case, technical debt items must be logged into the backlog, reviewed and prioritized just like any other ticket, of course with input from the dev team!
Tech Debt reduction must be part of your process. Remember that your time and energy are limited. Accumulation of technical debt needs to be under your control so that it does not become an obstacle for your team in the future delaying releases.
