"Refactoring" has become a buzzword. We don't say we're fixing our dreadful, messy code anymore, we say we're "refactoring" it. Sounds more dignified. But there is something to this notion, namely, that there is much greater depth to the business of producing quality code than meets the eye. Getting from first-pass code, even code that has been debugged, to true quality code is a lot more complicated than people realize. Even very experienced people may be cavalier and casual about the code they write, as if revisiting it were some kind of admission of incompetence.

There are several points to make about how we can existing improve code.

• Improvements should be made in many small steps. If you try a grand reorganization of the code, you will only introduce bugs and make matters worse.
• The small steps have to be verified by recompilation and re-execution of some minimal unit tests.
• The improvements consist of a few attributes of the code:
  • The resulting code is more extensible.
  • It is less error prone.
  • It is better organized (things are in their natural places), hence more transparent, hence more readable, hence easier to maintain.
• It takes time in the short run to revisit code that meets a minimal requirement.
• It saves time in the long run to make the kinds of changes that comprise refactoring.