What is the best way to explain refactoring to non-technical people?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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

Answer 10

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

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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

Answer 15

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.

Answer 16

"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."

Answer 17

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!

Answer 18

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).

Answer 19

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

Answer 20

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.

Answer 21

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.

Answer 22

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.

Answer 23

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?..

Answer 24

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.

Answer 25

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