5 ms·
The most frustrating part is explaining technical debt. From a business perspective you have a running software. You can sell it - it has all the features neede
by cntlzw 8y ago
The most frustrating part is explaining technical debt. From a business perspective you have a running software. You can sell it - it has all the features needed. Now you come along and tell me you need to fix something, that no client can see, that does not add any features and it might even lead to bugs. And you need two people and x weeks. I can imagine how "technical debt" is perceived as "snake oil" or "developer fun time" for management.
To avoid frustration it is best to fix technical debt in small steps, mix it in with others open issues. Devoting developer time for a big technical debt rewrite is hard to communicate.
- kylestlb 8y agoThe way that I've explained it with higher degrees of success is: "Feature X is used by a high percentage of users and also contributes to a high amount of bugs. We can invest two people and x weeks to bring those bug numbers down and product quality up."
- cntlzw 8y agoTotally agree with you. As other people commented here. The key to communicating about technical debt is numbers. You need some metric to at least show that you have a problem and a number to show that you improved quality after reducing technical debt.
- was_boring 8y agoI've used a similar approach for technical debt: 1) Get buy-in from the stakeholders that it's OK for developers to spend 30 minutes a day making their life better; 2) Communicate a vision for what the end goal is to the developers; 3) Get the developers buy-in. If the developers aren't willing to do it in small chunks, then it probably isn't bothering them that much.
- deleted 8y ago[deleted]