I’ve had some success by explaining these advantages:

1. Less bugs in the future (even sales people know bugs are bad).
2. Easier, faster and cheaper to fix bugs in the future.
3. Easier, faster and cheaper to make enhancements to the product.
4. Easier, faster and cheaper to add entirely new features to the product.
5. Easier, faster and cheaper to integrate with 3rd party systems.
6. The earlier you can start refactoring, the less technical debt you’ll carry and the better the product will be (1-5 will be easier).

I’ve had limited success with terms like technical debt, some commercial people get it, some think it’s just the techie people trying to justify doing their own thing, it all depends on the person you’re trying to explain it to.

One strategy that works well (as long as you don’t let technical debt accumulate too much) is paying it off a bit at a time by doing small-medium refactorings at the start of the next enhancement/feature/change that the sales people want.
Make it part of their request, “sure, we can do that, we’ll need to enhance this part of the system to support this new feature first though.”

If you can get actual metrics for how much time will be saved by doing refactorings then great, personally I’ve found that a double-estimate works better since all commercial people know stats can be manipulated and dev stats (depending on the person) can be seen as self-serving.
By double-estimate I mean “sure, feature X will take 3 days if we fix sub-system Y, otherwise you’re looking at X+Z days to work around it. Plus it’ll reduce our support calls and make the planned feature W faster to add.”

If people like metrics then combine the time spent on support calls about feature/product X with my double-estimate, this way you could produce a graph/spreadsheet/costings to show the cost of feature X based on on-going support calls with a reduction estimate from refactorings.
Over time, you could produce actual figures for feature X before and after the refactoring.

Getting actual figures for development costs is trickier since each feature is only implemented once (hopefully!) one idea is to keep track of how long the refactorings take and produce a double-estimate graph by adding in any refactoring costs as a “what it would have cost without refactoring”, which is hopefully higher than your actual estimate, this should make the time/cost savings very obvious.

Basically with a cleaner codebase pretty much everything can be done faster and therefore cheaper than it could otherwise, which delivers extra value and a better ROI for the commercial guys.

I find SteB’s answer (which I have upvoted) very good. I would like to elaborate on one point in his answer (as an example which might be applied to other points as well).

Easier, faster and cheaper to made enhancements to the product.

How to convince management of this?

Suppose you have just had release 1 of product X.

You already know that feature Y is planned for release 2 and feature Z is almost surely required for release 3.

Then you can make an estimate (perform a grooming session with poker cards) and afterwards go to your managers and say:

• With the current code, feature Y will take 8 weeks, feature Z will take 6 weeks.
• With the refactored code, feature Y will take 4 weeks, feature Z will take 2 weeks. Refactoring will take 2 weeks.

So you have the following scenarios:

1. Release 2 with feature Y. Feature Y costs 8 weeks without refactoring, 6 weeks with refactoring.
2. Release 2 and 3, with both feature Y and Z. Feature Y and Z cost 12 weeks without refactoring and 8 weeks with refactoring.

This is of course just a sketch but IMO if you can produce a similar analysis you might have more chances of convincing you management: it means you have a concrete idea of the benefits of your refactoring, even though it is only an estimate.

NOTE: If you find it difficult to produce a similar analysis, ask yourself what the chances are that you ain’t gonna need it.

I am with @maple_shaft’s comment above:

Don’t write bad code, even when prototyping. Think of your prototype code as a tracer bullet approach. Something that will become the final product even if it’s not there yet.

You do not need to explain or justify refactoring to management – it should be a continuous part of the process. Just like you don’t explain why you’re doing a specific inheritance structure, using a specific framework, etc. These are technical details. Your customers only care about the outcome, whether they’re management or end customers.

What you want to avoid is long downtimes where “nothing” happens as far as the outside world is concerned. E.g. you do not want to write a huge amount of bad code, then take 3 weeks to refactor it to make it good. First of all, it won’t work very well; and secondly you might get tempted to explain that you’re now taking time to refactor. Which to an outsider will sound like you’re taking some sort of geek vacation.

Refactor early. If you see something is wrong, and it would be a bit of a pain to make it right: Do it.
Addendum to that: If you are not sure something is wrong, or don’t know how to make it better, leave it alone until you do.

Been there many times.

There are some ways to handle it, no easy one though.

You almost said it yourself: they only care you deliver as fast as possible. Show the stakeholders a business case where a X month refactoring round will reduce the time it take to develop new rounds – and try to estimate some ROI – return of investment, after a year or so, for the refactoring.

Or, if this is very hard, there are other economical arugments that might help – “Given we are running a prototype in production, we need to hire two more engineers to maintain it. This cost can be avoided if we take on a refactoring project.”.

If you have internal cost centers etc. make sure the operational people supporting this application charges more for it, than similar “production worthy” applications.

If your team has some control, it might be possible embedd refactoring in the new feature deveopment phases. Say, they want to input complex hierarchies into an already shitty data model – include refactoring as a tech requirement to even make any changes to the data model. A similar case: if you ask your plumber to change the radiator, if the pipe is too rusty to function properly, he will prob. change that too, since its his profession to know what to do. The same thing (should) goes for software devs.

If you hit the wall, gather stats for your arguments. Tag each bug/operational issue that is reported that could have been avoided by production worthy code. Then you could show a business case by reducing the bugs with so-and-so many %, and increase the uptime/stability by another %.

However, there is always a fact that software developer want to make the best possible solution, when only “good enough” will do. If you can’t make up economical arguments for refactoring, it’s probably not worth it and should not be done.

Putting a prototype into production is worse than a poorly design project because too many decision makers believe it is better than it really is. Throughout the prototype building process, you were reminding everyone that “This is not ready for production.” The odds of getting to this point were low because they weren’t sure that:

• It could be built.
• Anyone was going to really need/use it.

Don’t focus on “I told you so” but make it clear you are not going to be able to maintain the schedule of the prototype nor can you use any of those metrics to determine how long it will take to create production ready features. They will see the product function, but remind them of problems such as:

• It may not be able to handle a larger number of users
• The error handling isn’t enough for the typical user
• It can’t accomodate many of the newly requested features.
• There is little to no testing

Non-technical members of upper-management aren’t going to grasp the concept of refactoring. They’ve got it in their head this “it works” and they will not release that thought for the entire length of the project no matter how many times you say something to the contray. You’re just going to have to make it part of your specifications. Technical managers may be under severe time pressure and may try and throw many of these tasks out of the project specifications. “Why are we working on features that are already completed?” Some of the other ansers provide some ways of explaining why this isn’t the case.

Good luck

I like to answer this through non-technical analogies.

Some examples:

You can easily build houses up to 5 stories tall with bricks. You can easily add on a single floor. But try and go to 20 or 30 floors and suddenly bam! the tiles are exploding because you need a better infrastructure like steel beams. Turns out that infrastructure is important and getting it right as early as possible through ‘refactoring’ the initial…

You drive your gar. All it needs to run is gas! Well, that and… oil changes frequently. Oh and infrequently, new tires, and occasionally other fluids and parts. Turns out that maintenance is part of being a responsible car owner…

Can you even unambiguously define what refactoring is? Merging two procedures is probably refactoring. But what about changing the name of an object? A method? A public variable? A private variable? What if you change the implementation of a method without changing its signature? What if that change makes it slow for a certain kind of input which in turn causes a change in a distant part of code? I guess what I’m saying is that you need a really clear definition of what you are trying to measure before you can choose a way or a few ways of measuring it.

This is also hard because you don’t immediately see the benefit of refactoring. Let’s say that you turned 5 objects with 12 methods into 3 objects with 5 methods. It will save you lots of time in the future, but it doubled the time you took to deliver the current feature. So it’s a short-term loss to the business for a hypothetical long term gain. Refactoring sometimes even makes things worse even though it often makes them better.

Let’s assume that refactoring means that a change in one part of the code requires you to change another part of the code in such a way that the functionality of the entire program is (more or less) preserved, but the way that it works internally is different. By definition then, the end user will generally not see the the effect of the refactoring (unless it improves performance or allows a simplification of the user interface which still provides the same baseline functionality to the user).

So you have to measure things in the long term to show a positive impact, and by definition it is an indirect impact. I thought about this all day today and it reminded me of a study published in Time magazine a few years ago about what makes people live the longest. Instead of asking people how much they smoked or drank carbonated beverages or whatever, they looked at the longest lived populations on the planet and analyzed hundreds (or thousands) of diet, lifestyle, and environmental factors to determine which ones were common among those where were long-lived and rare for people in general.

I’m sorry that I can’t think of a metric that you could measure every month and show with a little graph how you are refactoring better than ever, or directly correlate refactoring to your company’s bottom line. But I think you (or a CS department at an affiliated university) could look at characteristics of successful software teams to see if refactoring is something that sets them apart or not. I would suspect that it would, but would be extremely interested in seeing a study. Maybe someone else on this forum can point to such a study?

I have been in such positions (I suppose we all have.)

Quite often, this a very effective answer:

You have paying me for a year to develop this project. If I get hit by a bus tomorrow, do you want to pay someone for two more years, to figure
out how to unravel the mess I left behind? Are you not better off paying me for three months, so that the next guy will be up to speed in one month?

Important: Make sure you don’t get the boot when they hear you spent a year writing messy code, so you could get them a prototype on time…