>Ah, so you do it to learn the program at hand.
>
>Aren't you really saying that you prefer to "learn" a program that way than to read the code carefully?... and probably because the coding style of the original is not to your liking?

Spaghetti code, spaghetti code, shaghetti code... it's just sometimes too difficult to trace through without refactoring.

>
>Your "refactoring" and testing in little bits is a reasonable strategy, but you've surely got to agree that this method results in much longer development time than simply learning the existing code and changing as needed.

It depends on the end goal. In my case, the end goal was to learn the entire system, document it, and improve it where needed.

>And testing little bits at a time works nicely for the program at hand, but what about the application in its entireity?... a thorough system test? Are those charged with that duty even aware that you've chose to re-write a whole bunch of code? I bet that often goes unnoticed.

Yes, they are aware. I'm not saying you should just rewrite willy-nilly.

>
>I still see this as being done FOR YOUR PERSONAL CONVENIENCE, to the detriment of the client and the project as a whole. And worst of all, of course, is that the next guy having to work on the same code ALSO "refactors" it to learn it and to get it into his style! Since when has the price of fixing/enhancing an application included rewrites of all those components that need attention?!?!?

The main reason for refactoring is to make the code more readable!

>
>This buzzword - agile - essentially justifies an activity that has no business being justified except in extreme circumstances. We'll kill our business if we continue to let things like this become the norm.

Agile and refactoring are two different things.