What you need are Characterization Tests.

A characterization test is a test that characterizes the actual behavior of a piece of code. THere’s no “Well, it should do this” or “I think it does that.” The tests document the actual current behavior of the system. (Feathers, Working Effectively with Legacy Code, 186)

You can use characterization tests to develop documentation for the code after-the-fact. This is not the preferred way of doing it, of course; it is better to write tests before writing code. But when you are dealing with a legacy codebase (and according to Feathers a legacy codebase doesn’t have to be old—a brand new codebase has the same characteristics as an ancient one if it does not have tests) characterization tests are a great boon.

Feathers says (186):

Here is a little algorithm for writing characterization tests:

1. Use a piece of code in a test harness.

2. Write an assertion that you know will fail.

3. Let the failure tell you what the behavior is.

4. Change the test so that it expects the behavior that the code produces.

5. Repeat

Note that these tests are different that regular TDD tests in that they are not intended to describe what the codebase should do. They only describe what it does—which is exactly what you are wanting to determine.

If, of course, you find that it does something wrong, you now have tests that allow you to change this behavior with TDD. You change the test to expect what you actually want, and then fix the code until it does that.

Feathers has quite a detailed treatment of how to write such tests. He also discusses in other parts of his book how to get the code into a test harness in the first place (and thus he assumes it in step #1 above) but that goes beyond the scope of this question.

Throw it out and start over.

• It’s impossible to write code that other people can’t follow that you yourself can follow. Or that is even good. The code sounds not worth maintaining based on your few lines of description.
• Sounds like the kind of person who would leave logic bombs. Do you want to defuse them?
• Sounds like you’re about to greatly underestimate the cost of maintaining software.
• Fire the employee ASAP. He’s already voiced that he thinks the best way to grow in the firm is to contribute as much negative value as possible. He is working at negative value currently.

Sounds a lot like a project I’ve been working on for a while. When I was hired for the job I currently work at, I was given a folder on the desktop of an old machine and told that it was probably the most recent version of the code for a website. No documentation, code copy and pasted everywhere, some of the business logic in code, some of it in stored procs in multiple databases, etc. On top of that, the person I was replacing was the only person at the company who had touched that code so no one could really help me.

I’m still working on bringing that code up to some measurable level of sanity but this is what worked for me.

• Play around with the project: I just took a tour through our site (thankfully we had a beta environment I could do this on without fear of corrupting data, etc). I clicked around, tried using different features etc. I also looked at the code a bit while I did this so I could get an idea of what was where and how it worked.
• Fix a small bug: I started out with some small bugs and tried to fix them. It took a while to actually fix them, but I got more familiar with the system as I went. After a while it became easier and easier to find things and to understand the code. It’s still not a pleasant task to work on the code, but it has gotten easier.
• Keep at it: It’s not an easy thing to work on code with no help, but it does get easier.

TL/DR: Get a test environment and start messing around fixing bugs and playing with your app. Don’t give up, it will get easier.

What I would do is sit down at the keyboard, invent a problem, and try to solve it — that is, pick some part of the app and try to modify it. It doesn’t really matter much what you try to change — the act of digging deep into the code to make the change will force you to confront all of the bad coding practices as you try to understand them.

Dedicate lots of uninterrupted time to this task because you’ll need to get a little flow going. You’ll probably have to juggle lots of things in your head until you understand it all. Don’t take the problem lightly — it will take lots of concentration. Accept it as a professional challenge, and dive in head first.

I had a similar problem once, a long, long time ago. It was some gnarly database code written in fortran, by someone who I think only knew fortran-66. It had some nasty bugs that had eluded several people. I dove in, and I kept a log. I wrote out my thoughts as they happened — “oh, variable FOO is both a local in this spot and a global in that spot”, “this class is never used”, “this is sometimes called with three args, sometimes four, and the fourth is never used”, etc. This really helped as I slowly discovered the madness within.

It took me a few days, but I finally nailed it.

And talk to a lawyer. It sounds like you’re being blackmailed.

very simple?
I would just use the code and refactor/rewrite parts of it that need a change whenever it’s necessary.
You don’t need to rewrite all his code if it just works.

Edit:
Coming to think about the fact that he may be THAT Kind of coder,
There may be a few solutions that may be impractical but they may be worth mentioning:
1.hire an ex-coworker of his that knows his coding style.
2.hire someone that doesn’t comment his code, this kind of people understand each other best.