These are the two hurdles to work through first. I've seen people take over code that "worked good enough," and then get blamed for slacking or incompetence when it took them a long time to add new features. To avoid this happening to you, people need to know what the code looks like under the covers. Your boss being the author complicates things, but there may be a tactful way to approach the issue.

Were I in this position, I would first try to make things safe for my boss by leading off with something like "I can appreciate that you must have been working under non-ideal conditions when you wrote this, because I can see that you didn't have time to ...", and then see if you can't get him to agree that a bit of cleanup and refactoring is necessary before you try to add new functionality.

To give yourself confidence that you're not breaking things, you might want to develop some coarse-grained unit tests before you start.