Question: You've just written a pile of code to deliver some important feature under pressure. You've cut a few corners, you've mashed some code into some over-bloated classes with names like SerialIndirectionShutoffManager..

You tell your boss you're going to need a week to clean this stuff up.

"Clean what up?"

"My code - its a pigsty!"

"You mean there's some more bug fixing?"

"Not really, its more like.."

"You're gonna make it run faster?"

"Perhaps, buts thats not.."

"Then you should have written it properly when you had the chance. Now I'm glad you're here, yeah, I'm gonna have to go ahead and ask you to come in this weekend.. "

I've read Matin Fowler's book, but I'm not sure I agree with his advice on this matter:

* Encourage regular code reviews, so refactoring work is encouraged as a natural part of the development process.
* Just don't tell, you're the developer and its part of your duty.

Both these methods squirm out of the need to communicate with your manager.

What do you tell your boss?

Answer: 
I like the answer given in "Refactoring" by Martin Fowler. Tell your boss that you are going to develop software the fastest way that you know how. It happens that in most cases the fastest way to develop software is to refactor as you go.

The other thing to tell your boss is you are reducing the cost to make future improvements.
In my opinion, the simplest case to make for refactoring is fixing overly complex code. Measure the McCabe cyclomatic complexity of the source code in question (Source Monitor is an excellent tool for such a problem). Source code with high cyclomatic complexity has a strong correlation defects and bad fixes. What this means in simple terms is that complex code is harder to fix and more likely to have bad fixes. What this means to a manager is that the quality of the product will likely be worse, and the bugs harder to fix, and the schedule for the project ultimately worse. However, in refactoring out the complexity, you are improving the transparency of the code, reducing the likelihood of obscure / difficult bugs, and making it easier to maintain (e.g. a maintenance programmer can have a larger maintenance scope because of this).

Additionally, you can make the case (if it isn't a dead product in maintenance cycle) that decreasing complexity makes the application easier to extend when new requirements are added to the project.