2 ms·

I don't know that this is true for all technical debt. Generally there should be a motivation behind "fixing" technical debt that is expressible in terms of bu

I don't know that this is true for all technical debt. Generally there should be a motivation behind "fixing" technical debt that is expressible in terms of business value, whether that means faster page loads, more uptime, or ability to deliver X,y,z faster (or at all in extreme cases) If you can't express the trade-off of solving the debt in terms of business value then it's going to be low priority by definition. Another strategy for things that as engineers we know will make things better in the long run but show little immediate value can be to ask for a small amount of time per sprint/week to invest - ideally you should still be able to articulate why something is worth changing though

rualca 6y ago
> I don't know that this is true for all technical debt. Even if there might be some exceptions for some technical debt, it's always true from the product owner's and business perspective. Keep in mind that it takes resources, and sometimes even downtime, to address technical debt. In the POV of a product manager, addressing technical debt is an investment with the promise of little short-term returns with the tradeoff of significant risk in the form of downtime and regressions and bugs. And more importantly, technical debt is not a "one and done" deal. There are always more rewrites and refactoring to be done, and the one you're doing today might be the topic of technical debt discussions in the future.