I have a coworker who has been practically the sole contributor on a service for a number of years. For the most part, he does an above-average job. It works fairly reliably, it is thoroughly tested, and is relatively easy to read on a line-by-line level.
The software also has a lot of room for improvement. The details don't really matter to this question, but the flaws are completely uncontroversial to others I have discussed them with. Things like parsing a highly-nested grammar with regular expressions. He also takes decoupling to the extreme, to the detriment of other equally-important design principles.
These problems have built up over time, to the point where making changes now takes significantly more time than anticipated, and my coworker really needs help to keep the backlog from growing.
The problem is when anyone else tries to help out, he takes the changes personally, gets very defensive about his code, has difficulty admitting there is anything wrong with his design, and blames problems on user error or on code other people wrote. In other words, he seems completely blind to flaws in his code.
He is kind and pleasant about it, but also very stubborn, and will stand his ground for days, despite multiple people disagreeing with him. If we approach him before we make the changes, it's even worse, because he has a hard time visualizing the result. We don't technically need his permission to make improvements, but it is the courteous thing to do.
It is a draining process for everyone involved, and frankly, I don't want to spend the energy anymore. How can I approach making improvements to his code without having to argue (politely) for days to get it merged?