Personally, I no longer use the phrase "technical debt" when speaking to management. It's just too vague of a term. Instead I just explain the actual problem and the consequences - too much near duplicate code leading to slow maintenance, non-scalable design choices leading to slow processes, rigid design choices which hamper the team from implementing the upcoming stories, excessive complexity leading making the code hard to change.
Once you get our of analogies and into actual problems, then you can have a reasonable discussion about future tradeoffs. I find even with non-technical managers, debt/wealth is just not a good analogy for code.
Also, often poor code is just part of a larger process problem. You really need to optimize for the whole project, not just code-level to improve the situation.
Once you get our of analogies and into actual problems, then you can have a reasonable discussion about future tradeoffs. I find even with non-technical managers, debt/wealth is just not a good analogy for code.
Also, often poor code is just part of a larger process problem. You really need to optimize for the whole project, not just code-level to improve the situation.