Not all tech debt are the same
Choosing what to prioritize between developing new feature and fixing technical debt is a common problem that every software developers and product managers are facing on a daily basis. I get asked this question every now and then. It’s a valid question, but in my opinion putting tech debt in a single bucket, makes these 2 activities seems like a vastly contrasting choices. One is about the future of the product, adding capabilities to tackle more business cases, while the other caters more to the technicalities of the product. It’s not hard to imagine this will go on to the classic business vs tech narrative.
However, the reality is, not all tech debt are the same and the narrative of paying it doesn’t give value to business, is a false one.
Tech debt happens because it’s the best compromise that a technical implementation could provide, given exisiting constraints at certain point in time. The constraints can happen because of a business decision, external pressure, or even the technical capability of from both the developer side or the tool itself. Regardless of the source of constraints, it’s the acknowledged imperfect solution, trading off technical perfection in favour of delivering result.
In the end, overtime, this debt, just like any other debt (PSA: if you read this, time to check your personal finance and come back to this article later) could ended up as a huge pile of unpayable liabilities. And by that time it happens, it could either be the team is too crippled to solve it, let alone be productive, or the product suffers, unable to provide smooth UX or even growing to the desired state. I jokingly mentioned this to a colleague as “PayLater driven development”. The interest rate needs to be calculated if we’re to live with it. No one walks into the product backlog, see pile of tech debts and feels inspired.
So the first thing to do to rectify it is to think of tech debt as 2 different kinds:
- One that hinders the product to give smooth UX (the product still works, functionally correct, but the experience isn’t smooth)
- One that slows down developers from delivering more values
Having think of tech debt using this dichotomy, we can then have better argument on how to prioritize paying it given that we also need to deliver new features in the product. This will be contextual and we need to factor in other aspect, for example the current business direction, the team overall priority, overall mood of the team, the product state, and so forth. And we can do this on a per sprint basis.
For example, for a recently released feature that has good early traction, and business dictates that steering the growth of that feature takes higher priority than delivering a newer feature, we could prioritize solving tech debts that will contribute to smoother experience to make that feature even better. It could be a good time to refactor that frontend code to shave off some client-side processing.
On the other scenario, there could be a time where the required sign off for new features is 1 sprint away. This is a perfect time to tackle all the tech debt so that when the time comes to work on that new feature, the dev team can work in a better environment and more importantly, give boost to the overall team mood.
Another approach could be to take 1–2 day off each sprint to solely work on tech debt. Clean up that unused functions. Improve the API responses. Remove stale abstractions. You get the idea.
In short, handling tech debt per se, might not give straightforward business value. But rethinking them in terms of who will be the beneficiaries, provide better approach in prioritizing it during development. Always take care of the debt to prevent the product from degrading quality.
