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

Jim,
You have a point about not touching things that are working.

However, leaving poorly written code in place can be a disaster.
Poorly written code is already bug-prone.
Poorly written code that has been changed and patched numerous times has little chance of working correctly, and nearly zero chance of working under all scenarios.

If the program has been in production and appears to be working properly, re-writing for the sake of re-writing is a waste of resources.

What is more common is that someone is afraid of the old code, cannot decipher what the heck it is doing, and they patch rather than fixing it. Sometimes it works, and sometimes it gets really buggy.

Programming is expensive, and we should try the lowest cost option first.

We should NOT spend a lot of time and money chasing after cruddy old code.
I have tried that route with bad results.

Sometimes in refactoring the code, you eventually discover that the original coder was having a bad day or something and really did not understand the problem.

If the code was some monstrous run-on procedure that does many things and has lots of conditions - NOBODY is smart enough to predict what the code will really do. Add several changes and hacks on top of that, and it is hopeless.

In that case, refactoring for clarity is your cheapest solution.