I've written about technical debt already, but this is a good take on how to explain why it's necessary to clean up code to your managers.
The big problem is that managers are (usually) one-step removed from the code work, so they don't see the messy code, the compromised design, or the bubble-sort you used to get the last release out on time. So they don't see the roadblocks to adding new features very well.
And program/project managers are even further out of the loop on this - all they see is a UI and a list of features. They rarely have any idea that a working program could have crappy code in it - if it works it must be perfect, right?
So anything that makes it easier to explain why working code needs to be changed is a good thing. The best things are the metaphors that allow us to relate software refactoring to something the average manager can understand.
