The old man and the C

Another programming rant.
But his time, I have a person in mind. Our "Old Man".
The old man (I say old, since it is all a matter of mentality. He is 63 years old), has arrived in our company eight years ago. He was brought over from another company. Our CEO has worked with him before, and brought him to be our inspiration. The experienced man of the R&D tribe. Our elder huntsman.
Only, when you're surfing the leading the edge of technology, experience only takes you so far. There is just no way to keep up with he technology for so long.

Being a C++/Java oriented company, object-oriented design and programming is our pride and joy. We have made an art form out of breaking down systems into tiny objects/building blocks.
If there is anything that I've become an expert in over the last 6 years is that.
All HIS code could easily be compiled in C. He still thinks in term of "data-flow" rather than "object-interactions". Bugs the hell out of me. I asked him, in a round-about way, once, and he made it perfectly clear of how proud he is of his use of OO design elements and program structure.
The man has clearly no idea what he is talking about.

But that's not really what's bothering me. Bothers me the aura of "the experience" he has. It has certainly lost its shine with most people in our development team (including our VP R&D), but the CEO hired him, and wont fire him.

At least in his case, experience has seemed to bring mainly fear. He has been in charge of some of our software for six to eight years now, and is still mortally afraid of it. So afraid, in fact, that when we identify a problem in his code, he will do everything in his power to show us how to work around it, rather than actually fix it.
His catch phrase: "This code has a lot of CPU time under its belt".
So friggin' what?
There are thousands and millions of paths through the massive amounts of code that have been written in our company over the past 15 years. Some of them might still be faulty. Why? Because when it comes to the very basics, programming has a lot of copy-paste work. You look at someone's solution to a problem they have already solved before, and pretty much copy it. Especially when it comes to using infrastructure. These elements change very little, so their use is pretty much a mold pattern, copied from one program to another.
Accept the one time someone does something a little different; changes the order of operation of two, seemingly unrelated, things. However, because of some error in judgment, or simply a random decision or choice, done ten years ago by someone who failed to notice that relating the two operations made any difference, something could suddenly crash. No big deal. It comes with the territory.
But we don't fix things. Oh, no. Worst case, we rewrite them with a slight change, and force everyone to change the way they have worked so far to accommodate the changes. Anything and everything other than touching the existing code and fixing it.
Living in mild apprehension is good in any field of work. It will make you think twice about jumping into a fire with improper gear, or altering a piece of code that could drag a company into a legal battle with an irritated customer. Living in terror, however, just wont do. We wont have any fire-fighters.
And no software will ever be properly fixed.

My apologies for the stupid fire-fighters and programmers analogy. I was just trying to drive a point home.