How to convince my boss to do refactoring?

Question

Hi All,

We (developers) think we should do large grand refactoring in our project, because:

1. With long time (more than 1 year) bug fixing too much hard code/hard logic been involved.
2. Pickup one piece of code, nobody in this big team can confidentially tell you what will happen if you change that, because code are sticked together.
3. We are facing fidelity problems, that our software must give exactly same output for old input. In other side we have lots of new feature requirement. We want change code but every change may cause regression (fidelity) problem.

We want refactoring code to simplify the complexity, but we don't know how to convince our boss and ourselves. They need some thing to prove that work will useful.

The software we are working on is really big and complex. And the refactoring we planed is not a days job by one or two man. We have a big test team and automatic test utility (not Unit Test) but even that can not cover all our input.

Currently we are counting/classing problems in code by review bugs and codes, we try to find a way to which one should be refactoring first, but we are not sure if it's helpful.

Thanks, Trapped Developer in Large Complex Software

Answer 1

Metrics, and especially trends of those metrics over time, can go a long way convincing your boss about that 'refactoring' need.

Your count of problems can be helpful if they can establish a clear trend (more and more problems, longer time to fix).

You can also link the decrease of complexity with the cyclomatic complexity of your functions as long as it is related with the complexity of your unit-test cases you have to write in order to cover your code.

Plus if you make a dependency analysis, you can link the different cycles you find to the difficulty you have to fix one bug (because of all the potential side-effects you have to take care of)

All of those criteria (metrics, count, dependency) must be linked to a COST for the stakeholders, as opposed to estimated saving if the application is refactored and more easily maintained. If you have only technical criteria, however precise and detailed they are, they will eventually matter not very much. Some kind of ROI must be illustrated.

---

Basically, a scale refactoring involves rethinking the 'applicative architecture' (the way you assign different features to different applications - a launcher - a dispatcher - a GUI - and so on -, and that also mean to have an efficient way to make all those new applications communicate (usually, a communication bus comes along those kind of refactoring)

Of course, the use of a good Version Control System can also be needed to establish a parallel environment in which you can develop your refactoring. But you will need other environment (computers, network resources, ...) to launch your "parallel run" in order to measure your fidelity problem.

Do not forget that a parallel run should never be at 100% (that would mean you have successfully reproduced the bugs of your current application!)

Answer 2

It depends on how far you want to go.

If it basically amounts to changing almost everything around just short of a complete rewrite, then your boss will probably argue against it claiming it will be too expensive.

If it only involves little things, then do them when fixing bugs. That way the code is cleaned up gradually and tested along with the bug fixes to ensure it is still working.

Anything inbetween these two: I don't really know where to draw a line. It depends on your actual code.

Answer 3

You almost answer it yourself. The code is so cluttered that it's very hard to work with.

Refactoring code is not that much different from cleaning up your desk, reorganizing the stock etc. You can't work at a desk with so much paper that you can hardly find the keyboard. You need to organize the paper in binders or something, and throw out everything you don't need anymore. Until you do that, you can't find half the documents you need, and typing on the keyboard is awkward.

You need to clean up the mess, the sooner the better. Just because the boss don't see piles of clutter, it doesn't mean it isn't there. It probably just means that he haven't looked at (and understood) the code.

Refactoring feels like waste of time the first times you do it. But I have never spent time on refactoring, that I didn't get back, usually in a few days.

My advise (once you've cleaned up the current mess): Spend an hour or two every week to refactor the mess you've made the past week. It's really worth it! It comes from sloppy coding (we all have deadlines), something you've learned since you wrote the code (it seemed like a good idea at the time), and changes in the world around the app.

Answer 4

Two words Technical Debt. Google search you'll find a host of posts on this term. The greats:

• Ward Cunningham
• Martin Fowler

Explain it to him in '4-year-old' terms so that it has a greater chance of sticking. If the boss still does a PHB, go covert and refactor under-cover. Take care that you fly under the radar and refactor in small valuable steps.. no operatic grand changes. Split the refactoring cost across multiple bug-fixes.
HTH

Answer 5

State it in terms of how it will help the requirements, instead of how it will help you.

Meaning, instead of:

We need to refactor, because it has become frickin hard.

Try,

In order to meet changes X,Y, Z and deliver them with a high degree of confidence in quality, we need to invest some time into refactoring.

And, Gishu is right, for projects like these, there is usually no need to do a LARGE GRAND REFACTORING. Do it a step at a time, as you'll probably encounter lots of issues too if you try to do it all at once. (And eventually, a large change might not be really needed.)

Answer 6

Also make a point of a (rough) guess at the time cost, and what that means in terms of money, meeting deadlines and the like.

I have often suggested refactorings and told "I am being a perfectionist" or "I am being @nal" but then when I say that "feature x will take half the time, and we will actually meet deadlines, wheras if we don't, we will fail" - that can sometimes get managers attention pretty quick.

Answer 7

At my previous job, where no one used refactoring, as much as they didn't even know the word. I plainly told my Boss

 "Fridays I'll be refactoring the code, which means cleaning up all 
 the prototype code that got left in. That way next week's code will get 
 built on a more solid foundation".

He agreed and I was able to devote my Fridays to refactoring, which is a practice I'd advice for everyone and all shops.

By putting off the week's refactoring to Friday you assure you can work on your code all week, without wasting time refactoring stuff your still engineering. And when you come in on Monday's you actually don't feel like you'd want to kill the jerk that wrote all that stupid code last week :)

Answer 8

I was recently reading an early copy of Brownfield Application Development in .NET; now, while this is slightly biased towards .NET, for most of the time it actually focuses on the more architecture-agnostic issues - like: how to get is started, how to convince management, how to convince the team etc. Well worth a read.

Answer 9

Given your problems regarding fidelity and confidence in the code base, I would consider building a significant automated regression testing suite prior to going anywhere near refactoring. The reason for this is that you currently have something ugly and unwieldy that works, and refactoring without a good testing baseline is liable to leave you with something prettier that does not work, where you probably won't even know that it doesn't work.

Answer 10

I can tell you what the only thing that can convince me to invest time to re-factoring is answer to simple question "why ?" Ask your self this question and try to provide logical and backed up answer (please leave the answer "re-factoring is a good thing to do" for you colleagues and not for your boss).
Every investment we do should bring value real, real value. Usually the value is that next features will be implemented faster (by the way this answer i will not accept as well, without explanation how it will make the next feature implementation faster). There are additional reasons that you can find, but be sure that the reason is real and you can back it up.
Do not forget that i need to sell this re factoring to the marketing team and explain why i invest X resources to the re-factoring and to the feature Y that bring Z money.

In general it should be more easy and productive to convince the management to invest time to create infrastructures and resources such us coding convention, review process etc... to avoid re-factoring in the future.

By the way programmer (in my team) that will do the re-factoring under the radar probably will find him self fired :) From other hand if he has a good reason he probably will not have a need to go under the radar.

Answer 11

It's hard to "sell" refactoring. You need to build time for it into new functionality and maintenance tasks. You're actually in a good place because you have an (albeit incomplete) testbed. My approach would be this (and I've actually done this with success)...

• Utilize your existing testbed to start creating unit tests. Add tests for new features, recent bugs, and places where the existing test coverage is not the best. Don't misunderstand, you don't need to add the tests for the entire application before you start to optimize your code, but make sure a good set of tests are in place for the code set you want to refactor first. This has to be your first step! It's the only way to really know that you won't lose any preexisting (little known, rarely used) functionality in your refactor.

• As you start to work on new features or bug fixes, first refactor any code you believe will ease the addition of this new functionality. Work in small iterations - one refactoring task at a time. After each code change remember to retest and check in your changes! Continuous integration and testing will be the key to your success. After you're done with this "minor" refactor, add tests for the new functionality then code that feature.

That's it. Try to work in small increments and tackle this problem as a series of small refactoring tasks instead of one big one. Build time into the schedule of new requests for this activity.

Also, do yourself a favor and read Martin Fowler's Refactoring book. It does a much better job of explaining this process than I could in these few paragraphs.

Answer 12

A good article on this (and book)

Clean Code by Uncle Bob

Answer 13

Measure your velocity and prove your boss that non controlled technical debt kills your velocity. This is actually well known and is the reason why Agile teams do include "No increased technical debt" in their "Definition of Done". Without controlling your technical debt, you can't achieve sustainable pace. This is illustrated by the picture below (borrowed from the Technical Debt - How not to ignore it presentation from Henrik Kniberg):