Perhaps that "tested, trusted company code" is a steaming mess of spaghetti code that's been cautiously poked, prodded, and duct-taped over the years into something that in the end works but is a maintainability nightmare?
Probably. I've seen my share of that.
An interesting aspect is that a quick hack can actually be the fastest way to get the job done - in the first two or three iterations. But later on, the side effects of even minor changes grow dificult to contain and things that should be minor programming tasks start taking weeks.
So if you are content to use the old code exactly as it is, GP's approach of leaving the code alone is fine. But in my experience, sooner or later some business requirement comes up that means changing the functionality. At that point, the steaming mess of spaghetti code will really hurt you.
It is easy to fall into that trap, and getting out of it takes patient refactoring. Usually takes more time than a proper design would have taken in the first place.
We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -- Larry Wall
