[auganov]

So what's the business case? The fact that you hate the current code is not. As a manager (and a developer) I'd be very wary of letting a new employee refactor a project that they are unable to work with. If they cannot work with it do they understand what it does? Do they understand future plans of the company? Will their refactor be objectively an improvement? Will they even finish the refactor? Doing a major refactor is a major risk. I was involved in a couple of refactors that only resulted in a different mess. If you want to convince me to do a refactor I need a strong case that will answer all the doubts.

Sorry if I came across as harsh :)

[TheM00se]

The original engineer who came up with the code has laid out several key areas that need serious reworking within the documentation. The code base is a few years old and 30% of it is deprecated. In order to implement the new features, the code base will have to be refactored to better accommodate those features since the current code base has no such ability to accommodate such features.

[kohanz]

You're getting closer to a business case, but if you're confident in your assessment, you need to put it plainly, in terms that management can digest quickly. The bottom-line is money, and in engineering, time = money.

So here's the case: the time to add the new features on top of current implementation + the time to support this new, perhaps brittle, version = X. The time to refactor the application and add the new features + support the new, perhaps more robust, version = Y. You must show, in reasonable detail and with confidence, that X > Y.