>>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.

Don't know what happened to my first reply, buy here goes, again...

Yes, I think the discussion was fruitful.

As regards your list, I would qualify "you need to add functionality to an existing piece of code".
If the code base is reasonable (hopefully most is) and the new functionality is something like adding a new report or saving replaced addresses in a separate file or historicalizing records meeting certain criteria or things of the nature, then "refactoring" likely is not in order.
If, on the other hand, the task is to take a weekly batch job and make it a real-time affair, then likely very little of the original code will have value.

I think it all comes down to the idea that "refactoring" is not a default position, but rather a considered decision based on what's at hand in the current context and it is never based on personal preference.

cheers