We have a project on at the moment where we are refactoring an application that works fine for the moment but under the hood is beyond help. We need to rewrite it so that changes and maintenance can be achievable.

The problem is that after the project is done, the application will look and feel cosmetically and functionally the same. From a non-technical person's perspective, we'll have spent the best part of three months working on something that has no noticeable improvement at the end.

I'm wondering about the best way to justify what we're doing and why we're doing it.

How do I best explain the value of refactoring a project to someone who has no knowledge about programming?

+101  A: 

Show them a foto of cable mess and say that the application is like that inside - works, but drives nuts anyone who tries to make a change or investigate something. Cable mess is usually easy to understand for anyone.

+1 exactly my first idea
+1 I also like the term 'bowl of spaghetti'.
Good call. I use Christmas lights.
+1 Anyone have been involved in fixing come cable mess at one time, and it's hell. Can also say that this will drasticaly reduce the time needed for implemented new functionality and finding buggs, and in the long run will save the company money.
@Andy Who would need to tidy a bowl of spaghetti ^^
Here is a good picture for it :)
Thomas Winsnes
This is a fantastic idea.
+1 simple, elegant... brilliant :)
+8  A: 

You don't have to be technical to understand that refactoring is aimed at making something more readable, maintainable, and understandable.

This can be applied to many things outside of computer science and programming!

Explaining to management could be rationalized in the number of man hours to get a new team member up to speed and contributing. Before the refactoring it might have taken a month, now it would take a week, etc. etc.

Ben Cawley
+1 for recognizing that you need to sell this to management.
Is there any data showing that refactoring does improve the number of man hours to get a new team member up to speed, or is it just a rationalisation?
Pete Kirkham
That was simply a "stand to reason" statement and I don't have any immediate stats to hand to back it up.My thinking is that if something is clear, readable, and concise it is generally easier to understand then something that's verbose, and complex.I'll have a look through some of the craftmanship text's I've got, CodeComplete2 is a good one, and see if there's any hard data.
Ben Cawley
Just found a fantastic (IMHO) analogy for refactoring in "The Pragmatic Programmer""think of the code that needs refactoring as a 'growth'. Removing it requires invasive surgery. You can go in now, and take it out while it is still small. Or, you could wait until it grows and spreads, but removing it then will be more expensive and more dangerous".They also argue that as code ages, more dependencies are added naturally, which makes refactoring even more expensive.
Ben Cawley
final comment, just found an AMC paper on google scholar. I 'HAVE NOT' taken the time to read this a quick glance at the references show a fair number of scientific journal papers about refactoring. IF you are desperate for hard data then you could probably find something to support your argument by following the references.Hope that helps.
Ben Cawley
+1  A: 

Relate it to the Ford pinto - it all works, but has design flaws that requires a redesign. Hopefully, your application will not explode...

A bit of background:

the car's design allowed its fuel tank to be easily damaged in a rear-end collision which sometimes resulted in deadly fires


One of the main features of refactoring (and the reason it contains "factoring" within its name) is to remove unnecessary or duplicate information. A reasonably analogy is when you edit an essay to remove all but the most essential information. This can be viewed as "refactoring" the essay. Or when you factor a number into its prime components, or factor a polynomial by removing all but the irreducible components.

+11  A: 

I used to explain it as "fixing infrastructure so that further development can be made more easily"

Another way to go about it as: paying technical debt early so you don't have to pay it 10x or 100x down the road.

hasen j
second one is good, money talks
'Technical debt' is a good metaphor. Sometimes you want to go into debt in order to move quickly now, but doing so reduces your ability to act freely in the future.
Pontus Gagge
+29  A: 

Something like:

As you certainly know, maintenance costs exceed initial development costs for any substantial software project. By doing this behind the scenes clean-up of the code, not only will our effort in the immediate future be more efficient, but this will continue through the future also. Furthermore, the less complicated the code is, the fewer defects it will contain; this applies to past code as it stands today and changes that are made tomorrow.

Then throw in "ROI" and "6-Sigma", "TQM", and "WTFROTFLMAOABBQ" for Total Buzzword Compliance.

+1. Nice and simple.
+1, especially for the last part. Can't ever let those pesky managers think they actually understand engineering.
@Piskvor - thanks for the edit, ironically when I proofed I found I misspelled WTFROTFLMAOABBQ but missed "throw" ;)
lol @ Total Buzzword Compliance
hasen j
+1 for BBQ mmmmmmm
You forgot paradigm shifting!
+3  A: 

A program is like a house: over time, as you make additions and repairs, the underlying framework (plumbing, wiring, structural elements, etc.) becomes messier and messier; eventually it needs an overhaul. Even a well-maintained house needs a new roof after 20 or 30 years. While refactoring may result in little visible difference, if you have a vested interest in your house (or software project) you should know that it's necessary and even useful.

You say, "a well-maintained house needs a new roof after 20 or 30 years", and non-technician responds, *But in 20 years the software will be definitely obsolete! Come on, ship it!*
Pavel Shved
I think the analogy is bad: if you refactor as you go, software doesn't become messier; the refactoring cost is spread over time and insignificant. It's only when you postpone it that it gets bad.
Carl Manaster
Carl, you just proved my point. The longer you wait to fix something, and the quicker/sloppier the fixes are (i.e. kludges), the sooner you'll need to do a major overhaul (refactor). It's a sliding scale: if you fix things well and quickly, you will never need to do a major overhaul. But timely, efficient fixes are rarely seen in the real world (whether housing or software).
+2  A: 

I reckon, refactoring is made for product owner who's mind is about income. Question you should ask yourself is whether refactoring of this product will benefit your costumer economically not just because "cables will be easier to switch in future, using cable mess example"? You will work on this project for 3 month, possibly make mistakes in refactoring which will damage initial product and maybe this product will not even give the income to pay your costs.

Think about money not what is right, if you want to get this job anyway then use cable examples and fake costs to fix and maintain unreadable code which again you cannot estimate for sure as you don't know what is going to be next requirements to product or will it be ever updated at all.

Which brings us to main issue, refactor once you design initial product not afterwards.

+8  A: 

Show them There, I Fixed It. Explain that that's what the software looks like inside.

haha +1 .. that is exactly how most code looks like.
+1  A: 

You : We will be refactoring your project. Customer : What does it mean? You : You deserve better than this, so we will make better. Be Cool

Serkan Hekimoglu
I disagree: Refactoring doesn't directly give the customer a better product, so, in my mind, customers who hear this will be wondering what the developer is trying to sell them, and be frustrated when they don't see results. Refactoring is for developers to be better able to improve software for the customer, so its benefit to the customer is indirect. We should make sure our customers understand that if they have any input into refactoring at all.

Don't justify it. If it has to be done, do it. You are the expert right ?

Executives won't understand and if they do, won't see the value in it, so they will stop you in most case.

But... you should also question you why the application is in that state.

IMHO refactoring is a perpetual process that occurs while you are developing.

Pierre 303
It's not as simple as that. I don't have free licence to do as I choose without the approval of management. They pay my wages and want to know what I'm doing with my time. That should be obvious.The application is in "that state" because it was first built years before my or anyone else here's time. It has lived through many generations of changes by many different people and has eventually become untenable.
+2  A: 
  1. Pretty charts. Show software metric improving every day. Show how the class or dependency diagram changes every day.
  2. The 3 month estimate may be scaring off people. Use sprints. Try to come up with multiple smaller sets of refactorings that can be finished in each sprint. And tell the non-technical people that if they don't like it, they can stop the effort at any time.

Refactoring (Improving the Design of Existing Code ... from Martin Fowler's book) is supposed to be a series of many small changes, one followed by another, that are motivated by aesthetic design rules. If your planned changes are (1) big and (2) scary upfront, it may be a major re-architecturing effort. I'd suggest be honest, tell everyone it's going to be big, and explain why it's needed.

+5  A: 

So many answers already posted. Some even realistic in technical and business terms ;-) What I missed more prominently, was the question of responsibility.

I mean, is the proposer the author of the working mess and is the target of the motivational talk the one, that accepted the working mess? If so, my experience is, that it is usually working, to make him participate in error and success.

If the working mess was by another author, roll the drum and go marching with before/after demo slides, and the already proposed maintenance costs, learning curve steepness arguments.

If the working mess was accepted (conforming to a spec) by another person, than now being the motivational target it depends on the relation between the former and the current customer, how to proceed (in tone and content).

Better of course, would have been to deliver only working code instead of working mess in the first place, but this is often hard to decide on time and budget, although afterwards for everyone clear to see.


Best way is don't explain it. "RESPECT MY AUTHORITY!"

+2  A: 

Even if the people to whom you have to "sell" your refactoring project don't understand the technical details, they probably understand numbers as in money that has to be spent on programmer time for enhancements or fixes to the existing application.

Tell them that refactoring is all about making the code base easier to work with. Find a way to convince them that those enhancements or fixes to the application are going to be easier for the team and thus will take less time to market and less money that needs to be spent on programmer hours.

Of course, this will only make sense if they can see any future demand for fixes or enhancements.


"I'm sorry, but we have been screwing up and hiding it from you. Although we know that we have the responsibility to keep our code nice and malleable, we have failed to do that because we felt that you would be annoyed by the additional time it would take to deliver your features. So we never got around to it, and we never told you. And of course, you had no way to know, without us telling you. So now we're telling you: we need to fix this in order to keep working on it. And we don't want to ever let it get this bad again. We want to keep you in the loop and let you know, week by week, what the underlying quality of our code is, so that we don't need to take another three-month break from producing running tested features ever again. I'm sorry."

Carl Manaster
Maybe its just me but that sounds way way too apologetic. Though I guess that would work with some managers/customers.
Only the programmers here did not initially write the application and the ones that did are long gone. It was a mess when we inherited it. You sound fortunate enough to have never been in this position.
+5  A: 

In my experience it's not difficult getting management to understand what refactoring is. The difficult part is justifying investment in refactoring vs. investment in new feature X that could make the company's future. If you are proposing refactoring as a project, this is what you're up against.

To sell refactoring as a project, you need to speak business's language, and that's a language of metrics and dollars. Show them how expensive it is to add features to your application. Explain concretely, if you can, features that have hitherto been impossible or infeasible to attempt because of the current state of the code. If your project will result in performance gains or reliability, try to put a number on that gain and shoot for it. Give them concrete goal that you're shooting for that they can support. And, most importantly, do this hard business analysis yourself! I suspect many engineers often dream of stopping the company for 3 months so a bunch of refactoring can get done. Suppose you did that. It'd feel great for the first month, but it's not going to feel great if the company tanks after that because the customers' needs are not being met. Do the refactoring that needs to be done, but keep the project lean and mean.

Trust can be very important when selling a refactoring project. If you have a history of delivering successful projects, and have demonstrated to the business that you know what you're doing, you're much more likely to have management on your side when you say refactoring is necessary. Of course, if you were able to deliver successful projects with this app, you wouldn't be so desparate to refactor it, right? There's your dilemna. :-)

If you can't sell it like this, try a different approach: work refactoring into existing projects. A week or two of refactoring, maybe even a month on longer projects, can be presented as part of the cost of doing that project if the refactoring is actually related to that project. If you go this route, be honest with management if they want to know how you're going to implement feature X, but don't call out the refactoring as a separate line item if you can avoid it – make it a cost of doing feature X.

Finally, be assertive, and don't give up if management doesn't get it right away!

Hope this helps!

Owen S.
+1. For working refactoring into existing projects. You have to be pragmatic especially if you have a large amount of code. If a piece of code works, and there are no plans to change it, then it's a bad idea to refactor it. Wait until it needs to be changed, and then refactor it.
+22  A: 

The kitchen/cooking metaphor works pretty well. From Why Refactoring isn't popular?:

The typical example I give is what if a 5-star restaurant were to hire a lot of chefs and not enough dishwashers, and decreed that the chefs must ONLY cook, never clean up. Initially they'd be able to feed a lot of people, but as the dirty utensils and pots and pans build up, the chefs increasingly have to hunt for clean ones and a place to work. Gunk builds up on the grill. After a certain point, if we followed the typical IT shop solution, the restaurant would throw out all the dirty stuff, replaces the appliances that can't be salvaged, and if necessary hire new chefs.

Of course great restaurants don't work like that. They and their chefs are cleaning as they go, so that pan or knife that was used for the happy hour buffet prep gets returned to use for the dinner entree and then dessert.

Refactoring is cleaning the kitchen while you cook. It's not sexy, it doesn't make the souffle fluffier or the piecrust flakier, but it's a given that if it's not done, there won't be any souffle or pie at all.

A little variation (from this thread):

Refactoring is like cleaning the kitchen after each meal.

If you put it off, the first few meals take less time. However, the next few take incrementally more time. Eventually, you must waste time with extra tasks, such as evicting insect colonies from your kitchen. Very soon, the cumulative cost of the meals exceeds the cost of simply making dinner and cleaning up each day.

Robert C. Martin also uses this metaphor (see this previous answer).

Pascal Thivent
+4  A: 

I've always looked at refactoring from a mathematical standpoint, factor out that 2!

+1  A: 

Examples are good. I usually tell them about Netscape. You remember Netscape? In 1995 they had 95% of the browser market. Along comes Windows95 and Internet Explorer and with that the great browser war. Both companies are hurrying to get the most, newset, coolest features in every new version. At 4.01 Netscape developers say "We can't add a single feature more to this mess, it's starting to cost to much and incurring bugs. We want, no need, to rewrite it. It will cost you a year, but then we will beat Microsoft!" A year goes by, and another one, and another one, before Netscape 5 comes out. Netscape now have 5% of the market. Two more years and Netscape 6 is out, market at 2%. Now they are dead.

Continuous refactoring helps you from digging this hole that you can not get out off.

Thomas Nilsson
+3  A: 

I recently went to a talk by Ralph Johnson, one of the authors of the Gang of Four book. His talk was called 'Living and working with aging software' and specifically dealt with refactoring.

The way he analogized it was to say that refactoring was a lot like flossing teeth: it's something you do on a regular basis, almost without thinking about it. It is considered an essential part of the task. However if you don't floss every day, then eventually you'll have to have root canal treatment. If you're having to say to your business or product owner that you need to spend some time doing refactoring, then you're effectively doing root canal treatment on your code: something that is expensive, painful and very easy to have avoided if the code quality is looked after over time.

Noel M
+2  A: 

Strategy 1: For serious situations, come up with honest and accurate cost estimates (in person-hours if that's how you measure it) for known, required tasks after refactoring, those same requirements without refactoring, and the cost of the refactoring itself. Don't make up even your mind unless / until you have done this.

If you do still think a big refactoring or rewrite is in order, present your estimates in a matter-of-fact, objective way. Try to hide any pro-refactoring attitude so that your advice is taken seriously, and so you don't sound like an eccentric geek, or like you're just complaining about the situation. (I know you're not complaining; just make sure they know.)

Strategy 2: For every-day refactoring of code that you work on, refactoring is a technical detail that is none of management's concern. If-and-when it is appropriate to do it, just do it. I don't have a reference, but the Refactoring book suggests something like this. Just make refactoring part of your estimates of how long things will take.

If someone asks you about why things take you so long at first, then you can use one of the other great answers presented here to explain why you refactor.


A good way to justify refactoring is to tell user that new mods will cost more and take longer to complete, then you can explain the reasons. Specifically, why does it need refactoring, lack of design/programming specs?.. spaghetti code?.. design flaws?.. did you inherit someone else's mess?..

Frank Computer
I did inherit this mess. The reason this project needs refactoring is basically because any maintenance or additions to it are currently so difficult to accomplish within a reasonable time period and without introducing new bugs that it's not worth doing. It is pretty much spaghetti.
Would it be easier to re-design the schemas and re-write the entire app, while running the current app rather than trying to unravel it?.. what kind of app is it?
Frank Computer
+2  A: 

A code that is built by "copy and paste" is only good until the first time you need to change it:

When a bug is found, there is a good chance that the programmer that will try to fix it will not fix all the places with the same code (not in the program, not in other programs that integrates with the first and certainly not with projects that copied the bug). It's nearly impossible to maintain - especially when the bug is critical and must be fixed ASAP –

Not refactoring the code is the best way to kill the system slowly - where each bug fix - make the system less and less stable, reliable, understandable and fixable. I have seen more systems then I want to remember, that did everything they could to avoid refactoring - There were five different versions for each instance of the same function endless dead code(remarks) all because - nobody could predict if the code is there for a reason or not.

Clean refactored code - is easy to maintain both in time (=money) and in quality fixes.

Tell him:

  1. When there is a critical bug and there is no time to fix it – without refactoring a damage caused to the system by the fix is inevitable.

  2. Each bug will take much more time and will cost more. (And come on the expense of new developments )

  3. Every system should be replaced sooner or later and back engineering a bad system is mostly impossible – and a lot of very pricy knowledge is gone upon system replacement (not to mention that this knowledge should be acquired again).

  4. And don't forget to tell him that the cost of refactoring is only a friction of what what he will pay choosing the alternative.

Conclusion: because of Money, time, productivity (of employees without a system and of the programmers' team) and future lost of organization funds.

+2  A: 

If you like stock phrases, you can say "you can pay a little now or a lot later".

Andrew Grimm