What is Refactoring?

According to Martin Fowler, in his excellent book, Refactoring:

"Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs. In essence, when you refactor you are improving the design of the code after it has been written."

(by the way: I highly recommended this book to anyone interested in seeing excellent examples of Object-Oriented design principles in action. Even though the examples are in Java, they should all be readable to the Visual Basic programmer who knows even a little bit about creating classes. I used to think that good code looked like maybe 20- or 30-line routines with a lot of comments. After reading Fowler, I now shoot for 5-line routines with no need for comments, because the method calls are so well-named they're self-explanatory. Don't always get there, but I'm close much of the time)

In my programming practice, I interpret "refactoring" a little more loosely than Mr. Fowler - I often refactor while debugging, so the purpose of the refactoring is not always to leave the external behavior unchanged. Each individual refactoring will leave the external behavior alone (which is what makes it safe), but I use it to isolate and/or clarify a piece of behavior so that it can be reused by other code or extended. In other words, the refactoring doesn't change the behavior, but can be used as one step in a process whose goal is to change behavior.