The root of the problem is that your definition of "better" and his are very far apart. As far as he's concerned, he's at the top of his game: he's got job security and he does what he likes. What's to improve? He doesn't really care that his programs are messy and hard to maintain: he'll go in and fix it when it's necessary, right? Unless he really doesn't like spending time fixing bugs, he'll see no reason to change his style. (He lacks laziness, impatience, and hubris. ;-)

If you are going to try the carrot, find out what kind of carrots he likes. If he's turned on by tinkering, give him a box of his own to develop new ideas on ("Say Joe, what about this Zope thing? Bring it up and see if it's any good.") But make it absolutely clear that any and all production problems take precedence. That way he has a reason to write robust code.

Sadly, I've been in this situation a few times, and the only good solution I've found that worked was to bring in another person to train on the old system. That at least reduced my risk exposure, and allowed me to move the person into a position of less responsibility. (Although it sounds like you've got the additional problem in that he's an FOB: friend of boss. ;-) But it doesn't sound like that's an option for you.

I don't envy you. It's a tough problem.