How to build culture of owning technical debt?
Currently, we have tech debt mainly discoverable via a custom annotation in the code.
Some examples are:
- Break complex features into separate manageable flows
- Split large classes or controllers
- Feature/part refactoring tickets with linked ticket numbers.
The core tech debt is easy to address and manageable via project boards, but the problem is the rest (product related) often gets out of date and never gets resolved, for which there are some reasons like:
- The product team has been disbanded.
- Feature no longer a priority for the product.
- The part of the code has not been touched for some time but could come into active development again.
- Find better implementation of X
I believe the product-related tech debt should be owned and tracked by the product team but often there are some tech debts left in favor of speed like - breaking complex screens, and classes, and find better approaches etc etc
What's the best way to promote ownership and address such tech debt, so that they are addressed during code reviews and not left in the code as comments indefinitely, nor as a ticket in some project board which never addressed?
Discussion
(2 comments)- 5
a year agoSelfI found that a good way to do this effectively is to scope the technical debt issues you want to fix (ideally all the issues you are aware of) and plan what we call a "blackout" period that is dedicated to that work alone. During the blackout period the team will not work on developing any new features and will not do any other work except emergencies; they will only work on fixing the technical debt issues in scope. You choose the blackout time to be during a period in which the team is known to be free or less occupied (for example during the first week of next month). This way it's planned that the team will be working only on those debt issues during that time. Don't forget to involve the other teams that depend on your team so that they plan whatever they may need from you either before or after your blackout period. Also note to involve your testing/quality team and make sure you have prepared all the tests so that you can check that the new code still achieves what the old code used to do.
- 3
a year agoMeta, Robinhood, BaiduQuantify the impact of the tech debt. If you find it hard to measure or predict the impact, at least measure the effort needed. It's a typical case for "If You Can't Measure It, You Can't Improve It."
When you run into conflict with product decisions, quantifying the impact is the only right way to go. Talk about the benefit and costs of different options. "If we ship the product quickly, we are going to acquire this much of the market ahead of time and make this much of a profit." "However, if we leave the tech debt behind, we have this percent chance of having an incident every quarter, which will lead to losing this much money and the reputation loss will cause us this many customers down the line."
In theory, if you can translate everything in every option into $$$ (or other metric your team cares about), you can make an apple-to-apple comparison easily. That's a way to easily win (or lose) an argument, but at least the alignment is very clear afterward.
