Why refactoring?

Interesting thoughts about refactoring, starting with a comprehensive post by Jim Bird, stating what is not refactoring:

Fixing any bugs that you find along the way is not refactoring. Optimization is not refactoring. Tightening up error handling and adding defensive code is not refactoring. Making the code more testable is not refactoring – although this may happen as the result of refactoring. All of these are good things to do. But they aren’t refactoring. – in What Refactoring is, and what it isn’t

Then, there’s the obvious list of Refactoring Patterns, by Martin Fowler:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a ‘refactoring’) does little, but a sequence of transformations can produce a significant restructuring. – in Refactoring Home Page

Finally, a good advice from Joel Spolsky:

If you are writing code experimentally, you may want to rip up the function you wrote last week when you think of a better algorithm. That’s fine. You may want to refactor a class to make it easier to use. That’s fine, too. – in Things You Should Never Do, Part I