How to justify massive refactor / redesign

Question

Possible Duplicates:
How to convince my boss to do refactoring?
How can I convince skeptical management and colleagues to allow refactoring of awful code?
How do you justify Refactoring work to your penny-pinching boss?

I have been an independent software contractor for a couple years now, straight out of university. The code-base of one of my primary on-going jobs is incredibly messy and poorly designed... or not designed. I started on this job while in university. I would like to spend some (or a lot of) time refactoring/redesigning the code. I just don't like working on this project anymore because the code is so bad.

How can I justify to the client my spending a considerable amount of time (which equals their money) refactoring/redesigning the code?

I've been refactoring little bits as I go - but the code is so wild that I think such on-going refactoring will only help so much.

Answer 1

• Is it going to cut down on their support time/costs?
• Is the software going to run faster/more efficiently?
• Will this make future improvements/requests faster or easier?

There are reasons that can be a reason you want to refactor the code. However, keep in mind there are a bunch of drawbacks to refactoring too. You could introduce new bugs, and like you said, it's taking up a lot of the clients time & money.

Remember that software design is not something that is done for it's own sake. You are doing work for a client. Even if you don't like the code, if it's working fine, it will be hard to justify rewriting a lot of it.(See Joel's Things you should never do) There's no reason you can't make small improvments as you go along, and end up making a significant change. It's like the Grandfather's Axe parable:

This is my grandfather's Axe. My father gave it a new handle, and I've given it a new blade.

Answer 2

Client is not going to go for it unless you can show some business value to doing so. Remember a massive refactoring can introduce new bugs which users tend to get upset about and honestly if your car repair person told you he wanted to redesign the working engine in your car to get .2% faster performance or to make it easier for him to work on, would you agree to pay for it when all you wanted was an oil change?

Answer 3

Money talks. If you can show your customer how investing in refactoring would pay for itself in the future, it might just work. Something like: "After X hours of work on refactoring, implementing any new feature will take only Y percent of the time it takes now. So, after Z hours of writing new features, the investment has already been returned."

On a more personal note, I'd like to recommend that you read this post by Joel: http://www.joelonsoftware.com/articles/fog0000000069.html

Answer 4

It's always recommended to refactor piece by piece. Every time you need to build something, or need to change something, try to refactor that piece. In that way, you are still delivering added value to the system, while improving it at the same time.

Answer 5

I see this question come up a bit when people are exposed the the dirty dirty real world of code.

The general mantra is:

Ugly but tested production code is always better than pretty untested code.

Your best bet is to put the current codebase under test and refactor it into a good design.

All you will end up with at the end of your "rewrite to make it look better" is another ugly system that probably doesn't do everything the old system did.

So write unit tests for existing methods, get them to go green and refactor.

You will end up with a much better system than any that you would have designed/written from scratch.

The goal isn't to start over, the goal is to refactor the current code into something awesome

A good book / blog post on this subject: Clean Code by Uncle Bob

Answer 6

http://martinfowler.com/bliki/TechnicalDebt.html