3 ms·

i think riot put together a good article on technical debt: https://technology.riotgames.com/news/taxonomy-tech-debt https://technology.riotgames.com/news/taxon

i think riot put together a good article on technical debt: https://technology.riotgames.com/news/taxonomy-tech-debt https://technology.riotgames.com/news/taxonomy-tech-debt i stopped using the term technical debt. 'technical debt', 'refactoring', etc are not helpful to product owners. if something is contained in an area youre never touching, its not really worth even tracking because making it better won't improve any business metrics. tickets get lost, better to throw a comment in the code if anyone starts touching it later. If new functionality requires code changes, then that's just part of the requirements for that functionality. If some bit of code is slowing you down, then its a first class ticket to speed up developers, with explicit numbers on hours saved. at the end of the day, the business doesn't care about code quality, it cares about revenue/profit, so reframe any tech debt in those terms

gls2ro 4y ago
I think in some cases your proposal to not call it technical debt is indeed helpful. But I also think: 1) The term technical debt is here to stay and thus it is helpful to discuss about dealing with this data 2) I worked on multiple projects where we did not called it technical debt but code improvements. We were usually implementing some features with the purpose of testing it with real users as fast as possible and if validated it should be launched to all. In this case we were writing down what we left out from code design to hard coded values so that when the decision to implement the full feature comes to have a good start. In this case we were still discussing about code improvements and it what healthy for product managers to understand how come we can deploy so fast the feature working well for limited cases/users and then when deploying full scale we just need more time. I see companies where the business understand this as having an advantage in the market as good code design helps be prepared for changes.
- idunno246 4y ago
  I think I’ve just had too many discussions where someone’s complaining they aren’t given time to fix tech debt, and they think by calling it that it automatically qualifies for needing to be done. And the person that they’re asking time from just hears someone being a perfectionist. At the heart of it, it’s miscommunication. So I agree that the term is here to stay, but there’s better ways to communicate it to product/management. Like your example, making it clear to product what shortcuts were taken and how it will need time to fully implement. Code improvement vs tech debt doesn’t really make a difference, it’s just getting that conversation convincing

gls2ro 4y ago

I think in some cases your proposal to not call it technical debt is indeed helpful. But I also think: 1) The term technical debt is here to stay and thus it is helpful to discuss about dealing with this data 2) I worked on multiple projects where we did not called it technical debt but code improvements. We were usually implementing some features with the purpose of testing it with real users as fast as possible and if validated it should be launched to all. In this case we were writing down what we left out from code design to hard coded values so that when the decision to implement the full feature comes to have a good start. In this case we were still discussing about code improvements and it what healthy for product managers to understand how come we can deploy so fast the feature working well for limited cases/users and then when deploying full scale we just need more time. I see companies where the business understand this as having an advantage in the market as good code design helps be prepared for changes.

idunno246 4y ago
I think I’ve just had too many discussions where someone’s complaining they aren’t given time to fix tech debt, and they think by calling it that it automatically qualifies for needing to be done. And the person that they’re asking time from just hears someone being a perfectionist. At the heart of it, it’s miscommunication. So I agree that the term is here to stay, but there’s better ways to communicate it to product/management. Like your example, making it clear to product what shortcuts were taken and how it will need time to fully implement. Code improvement vs tech debt doesn’t really make a difference, it’s just getting that conversation convincing