You try to write the best code you can, but you can't predict the future and when you go back to some code it has "gone off" and you need to change it (it works, but you can't live with it anymore). You need to refactor.
"If it ain't broke, don't fix it" still applies. Still, you go back to the code and you just hate it. It doesn't make sense any more. So you should change it, otherwise you're going to end up with a right mess of code bolted on here and there. For examples see my page on AntiPatterns: Refactoring software, architectures and projects in crisis.
The book starts with an example, and then moves on to give a set of refactoring recipies. The point of the recipies is to make refactoring as safe as possible, so you follow the steps and the restructuring of the code should preserve the functionality (i.e., you won't have broken anything).
That's pretty much it, but the book talks about what makes code "smell bad", the thinking behind refactoring, and the sort of set-up you need to do refactoring (tests, source control...)
Related links