>Unfortunately users just don't care in most cases. Users almost universaly don't care. This also applies to businesses, C-levels and managers. However, while

>Unfortunately users just don't care in most cases. Users almost universaly don't care. This also applies to businesses, C-levels and managers. However, while they don't care it affects them indirectly as they end up using bloated sub-optimal software possibly with bugs and sometimes significantly slower than in could be. It then affects their productivity as well. My point is that one could at least try educating the non-IT decision makers why it's important. My team has successfuly convinced the CEO that 2 month long refactoring project is really important and that while it won't directly affect the functionality it will increase productivity of the our team in future by making the team more productive and allowing for faster implementation of new features in the future. From my experience the "technical debt" metaphor is great for explaining such things to business oriented people. That metaphor is usefull because it is compatible with other debt related metaphors, like interest rate or refinancing. We could explain extra time needed to implement stuff in non-refactored bloated codebase as an interest-rate. Also, the use of car-related analogies is quite effective. My point is that while users don't care about the technological intricacies, the effects can be explained by the use of metaphors and concepts that they know well.