Note: This document is work-in-progress. Please don’t publish it on news sites, or otherwise link to it in public without the author’s permission. Private linking is acceptable.
Refactoring is the process of improving the internal quality of the code (from “a big mess” to “squeaky-clean and modular code”), while not changing its external behaviour. This is done for mostly functional and bug-free code, but one which is not as elegant as it could be, so it can be better managed.
“Joel on Software” features two excellent article about the motivation for refactoring: “Things You Should Never Do, Part I” (why rewriting functional code from scratch is a bad idea), and “Rub a dub dub” (how and why to do refactoring).
There are many other resources for that on-line, along with many refactoring patterns.
There are many types of refactoring: grand refactoring sessions (= what Joel describes), continuous refactoring (refactoring as you go), “just-in-time refactoring” (refactoring enough to achieve a certain task), etc.
But refactoring is important, makes development faster in the long run (and even in the short-run), and can prevent the code from deteriorating into an ugly, non-functional mess that would be hard to salvage.