
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.
Just last summer I took over a project with over 250,000 lines of code. It was a complete disaster of a codebase, a total Rube Goldberg machine... but somehow, after years of poking and prodding and band-aids and what-not, it WORKED...however, even the tinest code change too weeks to happen because the code was so badly written. The project had a ton of turnover through the years, and from the looks of it many of the coders use conventions from different languages they were familiar with, copy/paste all over the place, bad structure, fragile inheritance schemes, etc., etc.
So, I did the only thing that made sense. Started completely from scratch, picking out the parts that were usable as we went. We haven't finished yet, but I haven't looked back...
Yes, but there's also when you hire the new guy, fresh from college, and he sits down at his work station. After a few days of getting absolutely no work done, he comes to you and tells you he wants to rewrite the core 50K lines of tested, trusted company code because he thinks it's not written "by the book". To which, the only sane reply is "You touch that code, and I will set you on fire."
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?
What you say may be correct for talking to the customer, but when one of the first level supporters (who presumably have at least a bit of experience) asks 2nd level to check server X, doing so might be smarter than to argue with the 1st level.
After all, the whole purpose of 1st level support is to solve simple stuff and escalate those things that are not obvious cases. If you treat 1st level like a potentially dumb customer, you end up with a $30/hour guy asking standard questions to a $8/hour guy.
Exactly what isolating 2nd level from the dumb customer was meant to avoid, only that you pay both guys for it
My fine-tuned and carefully-tweaked Windows XP box that I use as my main PC currently has 18 days of uptime. Windows today is simply not as unstable as Windows of yesteryear.
Did you know that if you took all the economists in the world and lined them up end to end, they'd still point in the wrong direction?