>RETRACTION: Article correct on refactoring, my reading was wrong!
>
>Martin and Ken,
>
>With the additional background provided by both of you I see now that I was overly literal in my interpretation of the article. I MISconstrued it to be saying that it is perfectly justifiable to rewrite (the original of the new-fangled "refactor") any code you dislike, the "Agile" principle giving one open license to do so.
>
>I am pleased to now understand that it is a decision to only be taken for good (and non-personal) reasons to improve the application's design, performance, reliability, maintainability or readability. The last one specifically should have nothing to do with personal preferences.

Nevertheless, this was all for a good cause, because it never hurts to give our theories, practices, beliefs and philosophies a periodic shake-up.

I think we've seen, in this thread, several cases when refactoring is not only recommendable, but is actually the best known way to save the day. And you've listed several cases when refactoring can be a sort of art-for-art's-sake mental extravagance and cause more damage than improvement.

If I may recapitulate this... refactor when:

- you have a lot work to do on an old app - you better do it right
- legacy code is actually an obstacle to functionality
- the rust keeps the ship from falling apart - untangling the spaghetti still leaves you with spaghetti; better replace them with something more digestible
- you need to add functionality to an existing piece of code
- ...everybody else chime in here...

...and my personal addition:

- you have a new way of doing things which can replace kilometers of spaghetti with much simpler and maintainable (and probably faster) code. Example for this was all the mFoxPlus code I replaced when we got SQL under the hood. All the temporary indexes, do while !eof()s etc were replaced with SQLs, and most of the reporting prgs went from 6 or 8 kilobytes down to 1.5 and were about 2-3 times faster and immesurably easier to maintain.