>I never saw the wisdom in re-writing code that is doing what it was meant to do, without problems or errors. We have COBOL code written in the late 60's that is still being used unchanged, except for the Y2K fixes. One of the problems with "upgrading" is the need to keep the old system running while the new system is being developed and test. This often requires a data structure compatibility, eliminating any advantages that a newer DB or language might bring. There is a HUGE inertial resistance to change.
>Besides, the legislature is always thinking up new things for me to do. I don't need to worry about rewriting a program that isn't causing problems and everyone is happy with.
>JLK

One reason you haven't seen the wisdom in "re-writing code that is doing what it was meant to do, without problems or errors" is simple. The wisdom isn't there. If there isn't a benfit to a business(or government agency) to make a change that someone wants to pay for then leave the code alone.

But when code needs to be rewritten, the refactoring techniques should be used. Refactoring is essentially taking exist code and rewriting it so it can be reused. This way we head towards the proverbial black box class. It works well in extreme programming environment(I love the names we have today).

My statement that "if it ain't broke your not trying hard enough" relates more to challenging the client to allow the code to do more, to add or improve features so he/she and I can make more money.