How do you justify Refactoring work to your penny-pinching boss?

Question

You've just written a pile of code to deliver some important feature under pressure. You've cut a few corners, you've mashed some code into some over-bloated classes with names like SerialIndirectionShutoffManager..

You tell your boss you're going to need a week to clean this stuff up.

"Clean what up?"

"My code - its a pigsty!"

"You mean there's some more bug fixing?"

"Not really, its more like.."

"You're gonna make it run faster?"

"Perhaps, buts thats not.."

"Then you should have written it properly when you had the chance. Now I'm glad you're here, yeah, I'm gonna have to go ahead and ask you to come in this weekend.. "

I've read Matin Fowler's book, but I'm not sure I agree with his advice on this matter:

• Encourage regular code reviews, so refactoring work is encouraged as a natural part of the development process.
• Just don't tell, you're the developer and its part of your duty.

Both these methods squirm out of the need to communicate with your manager.

What do you tell your boss?

Answer 1

This duplicates http://stackoverflow.com/questions/38144/how-can-i-convince-skeptical-management-and-colleagues-to-allow-refactoring-of

Answer 2

Lie. Tell him it's research into a new technology. Then tell him you decided the cost didn't justify the benefits. He'll think you did a great job.

lol @ people down modding / marking offensive.

Really, if it's a penny pinching boss, who doesn't understand good software from cheap software, what he doesn't know will ultimately make him happier. if it was me, i would leave the company and go someplace where they respect their developers ability to write good code. But then again, this is why I'm in a senior position.

Answer 3

Refactoring you should do all the time.... so you shouldn't have to justify it.

Cleaning up big messes / Redesign may include refactoring in order to get it under control, however its not "Refactoring"

Refactoring should be a matter of moments...or if you have no tool support, minutes.

Answer 4

I like the answer given in "Refactoring" by Martin Fowler. Tell your boss that you are going to develop software the fastest way that you know how. It happens that in most cases the fastest way to develop software is to refactor as you go.

The other thing to tell your boss is you are reducing the cost to make future improvements.

Answer 5

Tell him 80% of the costs associated with a software project comes in the maintenance phase of the lifecycle. Any refactoring done now to alleviate future problems, and have some examples, will net substantial cost benefits later on when the need arises to maintaining that code.

This is assuming you are refactoring for a reason and not for programmer vanity.

Answer 6

Just do it and schedule it into your normal process. Estimate refactoring time into starting a new change or into finishing a change (ideal). I always refactor while I'm initially exploring new code (extracting methods, etc).

Answer 7

Speak in a language he can understand.

Refactoring is paying design debt.

Ask your boss why he pays the company credit card bill every month vs not paying it until there is a collections notice. Tell him refactoring is like making your monthly payment.

Answer 8

Less money now for me to refactor...

or more money later to fix whatever goes wrong and for me to refactor.

Answer 9

In one of Robert Glass's recent books (I'll have to look up the reference) he mentioned a study on the cost of well maintained code. What they found is that well maintained code was edited more often than poorly maintained code. That sounds counter intuitive but when they dug deeper the discovered the reason:

Well maintained code has more features added to it in the same time frame than poorly maintained code.

Does your Boss like features? Sure, they all do. If more you improve the maintainability of the code, the more features you will be able to deliver with that limited budget.

Answer 10

Sometimes, it's just time to get a new job. There are certian poeple who just want you to "get it done". If you are ever in one of those situations, and I've been there, then just leave.

But yeah, all that other stuff about future costs and such is good idea. I just think that most bosses lie to themselves because they want what they want when they want it, and they are just not able to see what's going to happen in the future.

So, good luck with your boss. Hpefully he or she is reasonable.

Answer 11

Dont.... just go get a new job in a place thats more in synch with you.

Answer 12

I think you should just start working on it without telling your boss. This is truly how I've done my best work. I just don't tell my boss what I'm doing and slowly replace bad/legacy code when I have time.

It has acutally saved my ass on more than one occasion.

Answer 13

If your boss doesn't understand the need to refactor or clean up code, then you have to wonder if he has enough engineering knowledge to be an engineering manager.

Answer 14

It's important to include refactoring time in your original estimates. Going to your boss after you've delivered the product and then telling him that you're not actually done is lying about being done. You didn't actually make the deliverable deadline. It's like a surgeon doing surgery and then not making sure he put everything back the way it was supposed to be.

It is important to include all the parts of development (e.g. refactoring, usability research, testing, QA, revisions) in your original schedules. Ultimately this isn't so much a management problem as a programmer problem.

If, however, you've inherited a mess then you will have to explain to the boss that the last set of programmers in a rush to get the project out the door cut corners and that it's been limping along. You can band-aid the problem for awhile (as they likely did), but each band-aid just delays the problem and ultimately makes the problem that much more expensive to fix.

Be honest with your boss and understand that a project isn't done until it's done.

Answer 15

It's rare to find a boss who will give you time to refactor...just do it as you go along.

Answer 16

In my opinion, the simplest case to make for refactoring is fixing overly complex code. Measure the McCabe cyclomatic complexity of the source code in question (Source Monitor is an excellent tool for such a problem). Source code with high cyclomatic complexity has a strong correlation defects and bad fixes. What this means in simple terms is that complex code is harder to fix and more likely to have bad fixes. What this means to a manager is that the quality of the product will likely be worse, and the bugs harder to fix, and the schedule for the project ultimately worse. However, in refactoring out the complexity, you are improving the transparency of the code, reducing the likelihood of obscure / difficult bugs, and making it easier to maintain (e.g. a maintenance programmer can have a larger maintenance scope because of this).

Additionally, you can make the case (if it isn't a dead product in maintenance cycle) that decreasing complexity makes the application easier to extend when new requirements are added to the project.

Answer 17

The boss has to trust the dev to make correct technical decisions (including when to refactor).

Establish that trust or replace the boss or replace the dev.