Ask these questions about your lead.
- Are they used to working alone or with a very small team?
- Have they mostly coded at this one shop?
- Are they used to making the decisions?
- Are they used to "just getting it done"?
- Did they write most of the code?
If the answers are "yes", then I'm going to paint a picture of a particular type of lead programmer. If it matches up with what you've experienced, maybe it will help get into their head. If not, ignore this answer.
This is someone who has been there from day one, has spent years at the same job working on the same code base, is used to having their way, and doesn't have much experience with other ways.
They don't consider other people when writing code since it all makes sense to them. Of course it does, they wrote it, or they've spent years understanding it.
They consider coding style to be a personal preference, not a tool to reduce maintenance and bugs. When arguing about coding style they will struggle to hear your arguments because they've probably never thought much about why they do things their way. What they will hear is "I want to do it my way" or "I want to do it the new, fancy, trendy way".
They're set in their ways. Because they have been doing it the same way for so long all their tools and editors and brain micro-configured to exactly their style. Any deviation from this style will conflict with this carefully arranged, but very brittle, way of working. Attempts to change will draw complaints about their editor, tools, the way they like to work, or it being "hard to read". They reject change because they've wrapped themselves up so tight in the status quo they cannot change.
This is someone who has never properly learned software engineering and software architecture. They just sort of bang together whatever works.
You have a people problem, not a technological one.
You're going to have to retrain your lead, or you're going to have to quit.
Going to management is a last resort. Both for the reasons @JaredSmith pointed out and because you will lose. This guy has spent years making money for them. He wrote their company. He's put out in numerous fires. To you he's a cowboy chef making spaghetti. To them he's a hero that built and saved the company.
To retrain you'll have to...
- Gain his trust.
- Figure out how he thinks.
- Address his fears about change.
- Make changing easier.
- Show how this is better for him.
Take his style seriously and get inside his head. Ask him about it. Why does he do things the way he does? What does he see when he reads it? How does it interact with his tools? How does he move through the code? Knowing all of these things will allow you to understand and address his objections.
Find the objective root of his subjective objections, make them actionable. "It's hard to read" is subjective, and it gives you no information. You can't do anything about that. "I'm color-blind and syntax highlighting doesn't work" is objective, it gives you information, and you can do something about that. I would recommend a book called Getting To Yes for more on that.
Once you get at the root problem, the real problem he's experiencing, see if you can fix it or mitigate it. Then it's not a problem. They'll probably still have emotional issues with changing, but at least they can no longer argue it's an actual problem.
Do it a little bit at a time. This is someone who has been doing it the same way for years. He is used to seeing certain patterns in the code and using them to understand it. Suddenly changing all those patterns will be confusing. As frustrating as it will be to slowly bring them up to speed with known good practice, you have to walk him through it.
Advocate for a standard community style. This eliminates the argument that it's about personal preference and puts the pressure on them to justify why their different style is so much better. If you plan to be hiring, it makes it easier to integrate new hires.
Advocate for automated code style. Make following the correct style a push of a button. Use a tool that starts with a standard style, lets you configure it to your tastes, and can restyle the code with a push of a button. Making it as easy as possible to follow the style removes many arguments about how difficult it will be to follow. They can code however they like, and when they're done they push a button and it follows a style others can read.
Since this person is not in the mindset of thinking about others, you will have to show how these changes benefit them. It can be as simple as "since this is the standard now, you won't have to go through this fight again with the next person you hire". Or it can be "if we have tests you can be more aggressive about changing the code and worry less about changing things". Or "if there are good docs, people won't have to keep bothering you with questions about how the code works". For this to be effective you'll have to know what they want-- some people like to be bothered, it makes them feel important.
It's a long, long road. You'll have to decide whether you have the patience to manage up and retrain your boss. Think of yourself more as their teacher than their frustrated underling, and you might feel better about it.