How can I convince skeptical management and colleagues to allow refactoring of awful code?

Question

At work I have found it very difficult to 'sell' the idea of refactoring to management and senior colleagues. This is despite us having inherited a truly awful codebase (we all thought it was awful including them) from a programmer who really shouldn't be in the profession. I recommended over and over that we refactor and it simply didn't fly. The result was a project which has gone x4,5 over budget with a codebase that is so messy and hacky that maintenance takes an order of magnitude longer than it should.

This really is a depressing scenario, however senior colleagues and management are of the opinion that it would be a waste of the company's time and money (!!) to do so and that once something is done it's done. This is patently absurb given the disaster of the project I mentioned, yet they seem unable to snap out of this point of view.

Any opinions on how I could very convincingly sell this to people who are very skeptical? Or am I just wasting my time?

Answer 1

Do you have responsibility for any specific portions of this codebase? If so, you could refactor your own code into a more manageable format and demonstrate how much easier it is to deal with.

Answer 2

G'day,

Refer to specific examples from Martin Fowler's excellent book on Refactoring.

Come up with a good business case as to the benefits from performing the refactoring as well.

Management will only see the benefits in terms of ROI. That is, "ok spending this money will save me how much more money?"

That's what you've got to convince them of.

cheers,

Rob

Answer 3

Try refactoring a small part of the project on your own time, and then show them the results. Even if they don't like it, it's a nice addition for your resume as you start looking for a new job with colleagues that will better appreciate clean refactored code.

Answer 4

Maybe you need to break it down for them a little more. Create spreadsheet with four columns: "Task", "Time Taken To Complete", "Estimated Time To Refactor", "Estimated Task Completion Time On Refactored Code".

If at the end of the day "Estimated Time To Refactor" + "Estimated Task Completion Time On Refactored Code" is within the ballpark of what it is taking to complete the task using the old codebase (noted in the "Time Taken To Complete" column), then this is a no brainer.

Even if that number is twice as big, in the long run it would still pay off.

Answer 5

Instead of pushing for a full refactory try to sell them a partial refactory that will improve the code base as time goes on.

I would recommend you to make a plan. Document all changes that would be desirable to improve to the code base. Those changes would be done on a module per module basis.

Then, sell the plan to your colleges. Each module that needs anything changed gets refactored in the process.

As time goes by you'll end up with the code base you planed and all the time you had a product to ship.

Answer 6

To learn how to convince management, it's important to put yourself in their shoes and see things from their perspective. Learn what drives and motivates them. The key words are: cost, risk, liability, and benefit. You need to know how to quantify each of those based on your two potential courses of action 1) refactoring or 2) no refactoring. Put your data in a spreadsheet, do a cost/benefit/risk analysis, then present it to them. If the numbers are in favor of refactoring, they will either agree, or will question the accuracy of the inputs. In that case, have as much external data as possible to support the input numbers, including historical performance for your team, or recorded performance of similar teams.

Answer 7

I would be wary of refactoring in areas of code that you don't have a mandate to change.
Nobody will thank you if you accidently add a bug that makes it to the customer :-)

Answer 8

Every time I've seen code "refactored", it's been a disaster. And every time, the developer has "had to do it" because of the same reasons that you've described. I think you need to ask yourself if you really need to do this. And you need to get somebody who isn't you and who isn't invested in the project to look at the code and come to the same conclusion.

Ask your management to get the code quality rated by an external source. Tell them that you think the reason for the budget overrun is a bad code base. Try and accurately estimate how long it will take to refactor and how long it will take to complete as it stands. Try and get these estimates aggreed with by a trusted second party.

Finally, If your management are resisting your urge to refactor, then you may have to suck that up. Management are sometimes correct.

Answer 9

I probably shouldn't recommend this as good practice but when I start on grim code base projects I mainly refactor to read. If the code has duplication, 100 routes to the same effect or any number of those huge pungent smells that make a code base truely awful then I find it incredibly difficult to read without pushing the code around so it is easier to consume.

However, you have to be pretty good at this to ensure you don't change the eventual outcome of the code and limit the refactoring so you don't take it too far. It's better to get buy-in and do it properly and usually if the code base is too rancid then you'll need some serious architecture changes to get anywhere.

You have to advertise the ROI in terms of maintenance. Collect up all the stupid bits and pieces that mean things take longer and try to calculate it as a total cost of time so you can represent its monetary worth.

Answer 10

I wouldn't say you are wasting your time. I would say that there is a better way than trying to sell a "refactor" (which I would define as a "rewrite" with the language you are using).

Here's what I would do. As you work on specific sections of the code base, refactor and wrap them in unit tests, if possible. What this will do is clean up the most heavily used sections of the code first. Then create technical debt tasks to get to other sections when you feel it is necessary.

Also pick up a copy of Michael Feather's Working Effectively with Legacy Code

Finally, once you've had a go at this, you will have a solid business case in the instance where you really do need to rewrite it. You can present to management the work that had gone in, showing that you all truly took the time to understand the code rather than just adopted an NIH (Not Invented Here) stance (even if you didn't).

Answer 11

If it aint broke.

I'd suggest just refactoring portions as you get called in for a bug fix - refactor the method, or parts of the class to fit what you'd like to see, and then if you can see a better way of doing a section as part of a fix, go bigger.

But yeah, I'd say legacy code is legacy code - leave it be, as you need to do new things, wrap tests around what you can and move the quality of the code you write for it up.

Answer 12

@seanyboy

Every time I've seen code "refactored", it's been a disaster. And every time, the developer has "had to do it" because of the same reasons that you've described. I think you need to ask yourself if you really need to do this. And you need to get somebody who isn't you and who isn't invested in the project to look at the code and come to the same conclusion.

Ask your management to get the code quality rated by an external source. Tell them that you think the reason for the budget overrun is a bad code base. Try and accurately estimate how long it will take to refactor and how long it will take to complete as it stands. Try and get these estimates aggreed with by a trusted second party.

Finally, If your management are resisting your urge to refactor, then you may have to suck that up. Management are sometimes correct.

I think that's one of the most ridiculous answers I've seen on here so far!!! Refactoring is considered a good practice by pretty much the whole software industry, weird you're one of the few guys who seems to think it's a dangerous thing that requires some sort of arbitration process to possibly justify it... clearly you've been working with some very bad programmers, either that or the Dunning-Kruger effect is in full force!!

I think it's very silly to suggest finding some 'external source' to look at our proprietary source code at significant cost in money and time to determine whether it needs refactoring. Isn't that kinda what the programmers are paid for?!

The code very blatantly violates simple coding guidelines as specified by something like Code Complete. Everybody involved in the project agrees.

It often takes hours to write very simple bits of code because objects simply don't know about each other, the architecture is so bad it makes it impossible to achieve simple things. This simple project should have taken 2-3 months, it's taken 2-3 YEARS. This isn't a subtle problem at all. There are no post-mortems, no analysis, nothing. Management are so wrong it's ridiculous.

I really truly don't understand where you're coming from, perhaps you need to question yourself given pretty much the whole industry disagrees with you. Totally shocked someone can hold an opinion like the one you've just put forth. Yikes.

Oh and since we're on Jeff Atwood's site let's quote Coding Horror:-

Code Smells - "Any programmer worth his or her salt should already be refactoring aggressively"

Programmers and Chefs - "For software developers, working clean means constant refactoring. If you don't stop occasionally-- frequently, actually-- to revisit and clean up the code you've already written, you're bound to end up with a big, sloppy ball of code. If you forget to regularly clean up behind yourself, things get smelly. Working clean means following your nose and addressing those nagging issues before they become catastrophic."

Flattening Arrow Code - "One of my primary refactoring tasks is "flattening" arrow code like this. Those sharp, pointy barbs are dangerous! Arrow code has a high cyclomatic complexity value-- a measure of how many distinct paths there are through code:

Studies show a correlation between a program's cyclomatic complexity and its error frequency. A low cyclomatic complexity contributes to a program's understandability and indicates it is amenable to modification at lower risk than a more complex program. A module's cyclomatic complexity is also a strong indicator of its testability."

Eek!

Answer 13

Quote from Refactoring, Chapter 2:

What Do I Tell My Manager?

How to tell a manager about refactoring is one of the most common questions I've been asked. If the manager is technically savvy, introducing the subject may not be that hard. If the manager is genuinely quality oriented, then the thing to stress is the quality aspects. Here using refactoring in the review process is a good way to work things.

Tons of studies show that technical reviews are an important way to reduce bugs and thus speed up development. Take a look at any book on reviews, inspections, or the software development process for the latest citations. These should convince most managers of the value of reviews. It is then a short step to introduce refactoring as a way of getting review comments into the code.

Of course, many people say they are driven by quality but are more driven by schedule. In these cases I give my more controversial advice: Don't tell!

Subversive? I don't think so. Software developers are professionals. Our job is to build effective software as rapidly as we can. My experience is that refactoring is a big aid to building software quickly. If I need to add a new function and the design does not suit the change, I find it's quicker to refactor first and then add the function. If I need to fix a bug, I need to understand how the software works—and I find refactoring is the fastest way to do this. A schedule-driven manager wants me to do things the fastest way I can; how I do it is my business. The fastest way is to refactor; therefore I refactor.

Answer 14

The varying opinions here are rather fascinating. This almost seems like a religious issue to some. I own a business and I am a programmer. I can't tell you how many times programmers have told me that code sucks (sometimes mine - hey we all write bad code at some point). Being a programmer, I completely understand where they are coming from, and I also understand the value of time gained in the long run versus the short term delays. However, time costs and as the one who writes the checks and has to cover them, it comes down to a long-term vs. short-term benefit cost analysis. If it costs the business, let's say, $1000 to refactor and it can be shown that it will cost $2000 not to refactor because of the bad code, you just showed a $1000 savings. To a business manager, this should click, for as long as you can demonstrate the cost of not doing the refactoring. They will likely symphathize with your professional need to get it right, but they need to justify the cost/benefit, pure and simple.

You shouldn't have to do a complex business analysis, keep it simple. How much time will it take to refactor and multiply that by an hourly or daily cost factor (take your salary, add about 25% [this value varies from business to business, but 25% should be close enough for most] for overhead, insurance, etc. and figure out your hourly or daily cost). Now you have a cost to refactor.

$60000 Salary x 1.25 = $75000 burdened cost

$75000 cost / 12 months / 22 working days = $297.61 (Cost per day)

Now,

3 days to refactor the code x $297 = $891 refactoring cost (This is your investment)

On the next code change,

It takes 5 days to work the code WITHOUT the initial refactor (5 x $297 = $1485) If takes 1 day to work the same code that WAS refactored (1 x $297 = $297)

$1485 - $297 = $1188 (Savings) - $891 (Initial investment) = $297.00 overall savings

At this point, the investment has paid for itself, and any future savings are gravy and can be used towards productivity on other products, projects, documentation, billable work, etc. This was just an example, and you might find that it isn't worth it financially to refactor, or you might build a very strong case! Regardless of your religion on this, the numbers alone can speak volumes.

Time is an investment like any other. You can have the most beautifully written code ever, but if your company is out of business for poor financial decisions, the code doesn't do you much good anyway.

Generally speaking though, management may also have a very good reason not to refactor. It might have nothing to do with money or time, it could be a strategic decision or even a contractual reason you are not aware of (i.e. government work). Make sure you know all the whole story too.

I also see a lot of people talking about doing it on your time. This certainly shows conviction and love of your craft, but I wouldn't do it in a vacuum. I have seen programmers do this and cause havoc for other team members and the project as a whole. This is of course very general advice because culture and politics may play into this, but you may want to get buy-in before spending your own time to fix something, it may come back to bite you.

I hope this helps!

Answer 15

You could do something along the lines of Evidence Based Scheduling and start tracking how long various features take to implement. Do this for a few months. Then, start refactoring and see if the estimates and actual times go down.

Answer 16

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 17

I'm guessing since your boss is so miserly he's gathering detailed statistics. If the code base is so very bad, it will impact your estimates and also the accuracy of your estimates. That's measurable and can be shown to go up and down over time. Interesting ones would be the average overrun in terms of percentage points and average dollar value delivered per hour (or dollar) of actual programming done.

Offer to do a little refactoring on the weekends, nothing that will create a technical risk. Instead of asking for overtime ask for 50% of the average dollar value you can show you delivered over the first few months, tell him he can keep the value for the rest of the project lifespan. Clearly, if the project has at least a few more months to run, there is no possible way in hell that your boss will loose money on this arrangement. Even if you make a mistake and break something, you can roll back from source control.

If they don't buy into that then your boss is too stupid for words or he doesn't trust you - resign.

If it works, you get money for a new toy!

Answer 18

If you there doesn't appear to be a problem to management, you are wasting your time. At least in my case they have a list of thousands of items on their "hot" list for you to work on and fixing something that's not perceived to be broken is never going to happen... I often resort to guerrilla refactoring; when a fix needs to happen, increase your estimate to fix it as much as possible and then hopefully you might have enough time to refactor instead of writing an ugly hack to fix the problem.

Answer 19

Uncanny - you have just described my job! We inherited a truly appaling code base which began life some 13 years back as some form of Basic. It is now (allegedgly) VB.NET utilising framework 2 SP1 but contains all sorts of horrors left over from VB6, ADO 2, the .NET upgrade wizard, inline SQL (with field lists and counts in constants) and who knows what else. Although our business needed no convincing that it needed to be re-factored in a big way, they were sceptical about the perceived benefits. After all, the previous developer had consistently told them that each version would be an improvment on the last and it never was.

We simply did a quick tally of how many helpdesk incidents had been raised regarding this application and how much time had been spent resolving them (and the consequent lost productivity), took samples of a few error logs (many errors were never reported, just silently failed and no one was any the wiser) and, the coup de grace, we took some of the slowest performing SQL queries and re-wrote them. We demonstrated tangible benefits from the outset: In some cases, SQL query performance was improved by percentages with 4 or 5 figures and no decimal points (yes, really! That's how bad it was). This ensured we had full support as the business had to agree to having no new release for close to a year.

We are close to releasing now and although we are nowhere near finished the full re-factor, we have improved speed, stability and reliability enormously throughout the application. We also have plans in place for a complete re-write of the database (more speed increases) and in the meantime have also managed to implement multi-language support, which we hadn't planned on initially but it was sprung on us, and release a cut down version in both Spanish and, soon, Vietnamese. The business think we are heroes and they are so on board for the next two phases of upgrades that we could go on a cruise.

The key is to prove, even if it is only conceptually, that you will make a significant difference. Businesses rarely understand, or care, about maintainability because thats the techies job as far as they're concerned, but speed and reliability? Now you're talking. Prove that in a meaningful and targetted way, and explain your plans in plain English (or your native language) without recourse to jargon and technical slang, and you will win over many people. Remember, businesses will not undertsand or care about maintainability until it goes wrong, so push the tangible benefits hard and you get the maintainability as a freebie when you do your thing.