Q:

How do you explain refactoring to a non-technical person?

How do you go about explaining refactoring (and technical debt) to a non-technical person (typically a PHB or customer)? ("What, it's going to cost me a month of your work with no visible difference?!")
UPDATE Thanks for all the answers so far, I think this list will provide several useful analogies to which we can point the appropriate people (though editing out references to PHBs may be wise!)

A:

When you have a big home theater and you add things, slowly but surely a big rats nest forms in the back. 
If you are often times replacing parts, sometimes its worth straightening all that stuff out.
Sure, if you do that, it was working before, and it's not going to work better than when you started, but when you have to mess with it again, things will be a lot easier.
In any case its probably best to make a similar comparison to some subject area the PHB or customer is already familiar with, ie car or construction or something...

A:

Re-factoring is just like the process of re-packing a suitcase until everything fits in neatly. Sometimes, in the process, you wonder why you were trying to get so much junk in there to begin with.

A:

I wouldn't explain the concept of technical debt, because it's not necessary. Instead, focus on refactoring: You are changing the design of your program, not necessarily so that it is "better" or "improved,"  you are changing it so that it can accept a change that you need to make.
A car analogy might fit: You need to add an air-conditioner to a car, but it wasn't originally designed for one. Not only do you have to make a weird L-shaped air-conditioner, but you also need to move some other things out of the way first and change the venting system.
I also think it's a better strategy to refactor when you are accommodating new features: otherwise you might be changing the design into something that only looks "better," but might actually be poorly suited to the circumstances surrounding the addition of your next feature.

