All submits should start with a score of 100 and should be able to slip into negative infinity.

Your coding standards should be written in such a way that they can be difficult to understand and abused for your own purposes. Always allow for exceptions to any rule, but that they have to be allowed by a select few (only yourself if possible).

You should use things like poor comments to beat people over the head to show them how much smarter you are as well as deduct points.

Don't actually give out the coding standards or code review documentation to anybody, make sure that you make a power point presentation that 'dumbs it down' for everybody, this will make them feel better about the doing the reviews but still allow you to nit pick over every little detail.

Remember to ensure that your submits come in from 90-100, so that you can beat everybody else out but still show improvement from time to time.

Finally, you should always wait until the last minute to do any code reviews and enforce standards, this way you can ensure that you really only review the people who you want to chastise with a lower chance of repercussion from others reviewing your own code.

P.S. also ensure that you promote people committing directly to trunk and causing the most amount of breakage possible, that way you can deduct points from their code review because you should have a note that for each code breakage infraction they lose points.

Coding Standards and Code Reviews. Then you'll have some more process in place that he won't care about. From previous experience they'll probably all get waived in favor of the almighty deadline anyways!

Yeah yeah... I know the horrors of maintaining somebody else's junk code... but what coder hasn't left behind them a trail of woe and destruction? Also, have you ever considered that it might be you? It sounds like more of a potential ego problem than a who is doing it write. Sure the code may suck to maintain, but if the guy is hitting deadlines and the sky isn't falling (until the maintenance crew touches it)... well who's to say who is write or wrong? Unless you get management to sign off on a specific plan, or can explain why OO is better than monolithic scripts... you're not going to have any way to show this or that.

At any rate... rewriting something that works (even poorly) is a massive undertaking... and you'll be fighting a losing battle of playing catch up. Unless you really like coding a lot, and overtime even more you should really consider if it really is worth the fight for you. I worked at a place that I convinced management to convert from procedural code to object code, and even with full backing everything went to hell over two years... and guess what the old system was still functional while the development team went of to write code for new features of the system because they wanted to solve interesting problems and not port code over that solved current problems we needed.

What you really should be focussing on is how do you put yourself into a position to write 'beautiful' code so that everybody else has to be stuck maintaining your code.