I think tech people should just explain to business people the consequences of ignoring the tech debt.
From what I've seen, managers and product owners tend to ignore tech debt, because repaying it usually means performing refactoring, and refactoring doesn't bring any new features to the product. So it appears useless to people who are interested in revenue. And if those people come to understand that tech debt will eventually lead to decrease in revenue then it's likely they will do something about it (or so I hope).
It would be great if developers could have a fixed amount of time (and budget) to do tech tasks.
Other problem which I've encountered in some teams is that developers are required to estimate the time for completing a task in hours and after that those estimates are treated as deadlines. Add tech debt and missing knowledge about some parts of the project you're working on to the mix, and say 'hi' to overtimes, because you have to meet deadlines somehow.
I wish it were that simple. But I think the problem is tougher than that.
I think that the most productive way forward is to start from the premise that the business does understand technical debt, but that they don't have enough visibility into how much has been accumulated, and what the likely effects of that debt load are. They need to be kept updated about how the technical debt is slowing development, causing more issues to be found in QA, requiring developers to work extra hours, increasing the frequency of production issues, etc. I'm a believer that open, clear communication really does improve decision-making and relationships within the business.
Unfortunately, I think it's often true that the business does understand technical debt, and it's consequences, and that they've consciously decided that those consequences are acceptable, even if they make the dev team miserable. If that's the case, your best option is to keep an eye out for a happier place to work, and move if/when you can.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think tech people should just explain to business people the consequences of ignoring the tech debt.
From what I've seen, managers and product owners tend to ignore tech debt, because repaying it usually means performing refactoring, and refactoring doesn't bring any new features to the product. So it appears useless to people who are interested in revenue. And if those people come to understand that tech debt will eventually lead to decrease in revenue then it's likely they will do something about it (or so I hope).
It would be great if developers could have a fixed amount of time (and budget) to do tech tasks.
Other problem which I've encountered in some teams is that developers are required to estimate the time for completing a task in hours and after that those estimates are treated as deadlines. Add tech debt and missing knowledge about some parts of the project you're working on to the mix, and say 'hi' to overtimes, because you have to meet deadlines somehow.
I wish it were that simple. But I think the problem is tougher than that.
I think that the most productive way forward is to start from the premise that the business does understand technical debt, but that they don't have enough visibility into how much has been accumulated, and what the likely effects of that debt load are. They need to be kept updated about how the technical debt is slowing development, causing more issues to be found in QA, requiring developers to work extra hours, increasing the frequency of production issues, etc. I'm a believer that open, clear communication really does improve decision-making and relationships within the business.
Unfortunately, I think it's often true that the business does understand technical debt, and it's consequences, and that they've consciously decided that those consequences are acceptable, even if they make the dev team miserable. If that's the case, your best option is to keep an eye out for a happier place to work, and move if/when you can.