How do you go about explaining refactoring (and technical debt) to a non-technical person (typically a PHB or customer)? ("What, it's going to cost me a month of your work with no visible difference?!")

UPDATE Thanks for all the answers so far, I think this list will provide several useful analogies to which we can point the appropriate people (though editing out references to PHBs may be wise!)

  • I don't remember how Apple convinced so many people to change from Leopard to Snow Leopard. Probably the price: $100 less than usual at the time.
    – mouviciel
    Commented Dec 5, 2011 at 14:14
  • This question could yield some surprisingly useful responses for anyone working with code in industry. Pay attention people. Commented Dec 5, 2011 at 14:36
  • why would it be wise?
    – Louis Rhys
    Commented Sep 25, 2012 at 1:52

21 Answers 21


When you have a big home theater and you add things, slowly but surely a big rats nest forms in the back.

If you are often times replacing parts, sometimes its worth straightening all that stuff out.

Sure, if you do that, it was working before, and it's not going to work better than when you started, but when you have to mess with it again, things will be a lot easier.

In any case its probably best to make a similar comparison to some subject area the PHB or customer is already familiar with, ie car or construction or something...

  • 1
    Not the best analogy because it makes it sound like bad stuff just spontaneously crawls into your theater, as oppose to the bad stuff appearing as a direct result of continuously building your theater. Commented Nov 10, 2010 at 7:29
  • 22
    @Axidos: "rats nest" is an English idiom that means "a seemingly impossible to undo tangle" (in this case, of cords and cables behind the entertainment center)
    – HedgeMage
    Commented Nov 10, 2010 at 8:08
  • 8
    Conceptually its pretty good - needs "of cables" after "rats nest"
    – Murph
    Commented Nov 10, 2010 at 8:29
  • 2
    @Peter: I think we've all had to go behind the TV at least once though. Just explain it as a hundred times worse and spin a yarn of cables everywhere and pull this and pull that and discover a dead civilisation somewhere in the mess. Commented Nov 10, 2010 at 13:22
  • 3
    If someone can't relate, show them this: google.com/images?q=do+not+touch+any+of+these+wires
    – Steve S
    Commented Nov 10, 2010 at 16:30

Re-factoring is just like the process of re-packing a suitcase until everything fits in neatly. Sometimes, in the process, you wonder why you were trying to get so much junk in there to begin with.

  • 1
    I was going to post some analogy with a garage or shed, but this is better.
    – Matt Ellen
    Commented Nov 10, 2010 at 12:02
  • Or sometimes you go buy a few more suitcases and realize that paying the overweight charges is no big deal, since in software costs are not equal to those in the physical world. Then you can really fit everything in nicely and the constraint of a single suitcase turned out to be arbitrary and absurd. Commented Sep 26, 2012 at 0:25
  • +1 This is great. As well as making things occupy less space, there is stuff you realise you didn't even need at all and so can leave out.
    – Robbie Dee
    Commented Dec 21, 2018 at 14:46

I wouldn't explain the concept of technical debt, because it's not necessary. Instead, focus on refactoring: You are changing the design of your program, not necessarily so that it is "better" or "improved," you are changing it so that it can accept a change that you need to make.

A car analogy might fit: You need to add an air-conditioner to a car, but it wasn't originally designed for one. Not only do you have to make a weird L-shaped air-conditioner, but you also need to move some other things out of the way first and change the venting system.

I also think it's a better strategy to refactor when you are accommodating new features: otherwise you might be changing the design into something that only looks "better," but might actually be poorly suited to the circumstances surrounding the addition of your next feature.

  • Moving the parts in a car to give better performance or easier maintenance - works for anyone who's lifted the lid on their car, but how many PHBs have done that? Commented Nov 10, 2010 at 10:47
  • 3
    I like this one because it emphasizes that the refactoring is being done to make a required change easier (or possible). Refactoring should usually not be done for its own sake, but to meet a specific goal. Commented Dec 9, 2010 at 18:58
  • So, the short answer becomes: Don't tell them! Just factor in the time into new features and refactor accordingly. Commented Sep 20, 2018 at 9:40

I use the term Technical Debt and relate it directly to something they understand - Corporate Debt. Technical Debt is like taking out a loan. You pay interest on it. E.g., you can build a new factory and pay for it outright or you can get a loan for it. If you get a loan you will actually pay more for it in the long term, but it makes sense financially if the terms are right.

However, if you are paying 25% interest on such a loan you put yourself into a non-sustainable position. This is the same with technical debt. Sometimes it makes sense to take on some technical debt. However, there comes a point where the interest is too high and it needs to be paid off. Some techincal debt is like a home loan and some it is like credit card debt. In emergencies credit card debt is an important and valuable asset. However, it can also break the bank (or household if you choose) if used unwisely.

Another example: you can pay $10,000 for a marketing mail drop to garner more leads for sales in the future. You are paying off "sales debt". This is an expense with long term payoff. Equate this to why you would want to "spend" money now refactoring a piece of code. In both cases there is no immediate payoff, but you are setting yourself up for better performance in the future.

I tend to use the term "xxxx debt" as an analogy when talking to whomever the target audience is. E.g., Operational Debt - The printing press we have now works well, but by stopping production for one day (or one week) and upgrading to a new machine we can increase output by 25%.

EDIT - Here is another take on this

  • 1
    +1 for a well reasoned reply that demonstrates realistic economics. Debt is rational at times, and purists miss too many opportunities if they cannot tolerate it.
    – Macneil
    Commented Nov 10, 2010 at 18:01
  • 1
    And people understand that taking out loans to pay the interest on older loans is not sustainable. Commented Nov 11, 2010 at 1:38
  • 1
    This is my preference for explanation, because I like to refer to scrapping everything and rewriting (which often is the only option left due to so much technical debt) as technical bankruptcy Commented Dec 5, 2011 at 13:11
  • 4
    This is a terrible answer. (1) This is more complicated than the technical explanation of refactoring. (2) This doesn't explain the "why"s of refactoring; it explains the "when"s of refactoring (ie: when it is cost effective). Or maybe I really just don't understand this post, and hence point (1). Commented Sep 25, 2012 at 0:54
  • 2
    @ThomasEding (1) This is not an explanation of refactoring, it is an explanation of technical debt. (2) This does explain the why of when to refactor - to a business person. Honestly, they don't care about the technical reason, you do. They want a justifiable reason you are working on something other than the next feature that will drive sales. This is why most programmers can't talk to their boss and complain the boss is stupid. They are not stupid, they just have different drivers than you.
    – Nemi
    Commented Sep 26, 2012 at 20:03

Spring cleaning.

You aren't doing any modifications to the house. You're just shifting stuff around and getting rid of some of the dust. Maybe throwing some things out that you don't use or need anymore. but you're not adding anything.

  • 1
    +1: This is the best answer imo: and pretty much anyone can relate. "You live in your house, things get dirty/dusty/modly - periodically you need to do a deep clean." Commented Nov 10, 2010 at 20:44

"Have you ever played Mouse Trap? As we stick in new features, change interfaces, and fix bugs, code can start to look a lot like that. There comes a point where we either have to expend a lot of capital (time and effort, which amount to money) making sure all the moving parts play nicely with each new change or addition, or we can instead set time aside to refactor the design, resulting in fewer moving parts we have to manage each time we make a change. It may seem, from an end-user's perspective, that the refactor doesn't have any benefits, but the benefit happens every time a new feature is added post-refactor. The process is faster, introduces fewer bugs, and is less expensive thereafter, not to mention that the refactored code is often more efficient overall.

You may wonder why we let it start to look like Mouse Trap in the first place:

  • Sometimes getting something done right now means that we have to sacrifice elegance and efficiency to just "make it work".
  • The language features and other technologies available to us as programmers often change. Sometimes new features let us replace a finnicky jumble of six moving parts with one.
  • Oftentimes, when we add feature C to features A and B, we don't know that B will eventually be dropped and D added. One way to accomplish C may work very well with B, but not very well with D.

In an effort to keep building a better mouse trap, we have to constantly go back and find places to reduce complexity and streamline what we have. It's the difference between just having software with a lot of features, and having truly high-quality software."


alt text

This is a slightly more graphical version of the home theatre analogy.

If you want to add one more new appliance [aka, new functionality], at a pinch you can probably fit it in somewhere.

If you want to add yet another appliance, you can buy an extension lead, which will buy you some time.

But at each addition, it becomes more difficult to find a solution. And you're exposing yourself to a risk1 of fire [aka bugs], and you will have to pull out the big bucks to pay someone to put new sockets into the wall, which could quite possibly escalate all the way up to the main circuit board, or even further.

1 Another thing PHBs don't grok very well: "Well if it only might happen, what are you worrying about?"


Refactoring - is like organizing your clothes cabinet / Tool Drawer.

  • You dont throw away your clothes /tools just because they are all over the place.

  • You could argue that they should never get disorganized. But they do.

Just like code does. Especially as it grows over time.

And if you dont clean it up, you will keep wondering what happened to that t-shirt you loved or that wrench that you always need but can never find!


I would say ”code maintenance”. It's important to use words that the non-technical person is familiar with and that make sense to a non-technical world view. If non-technical person (customer) is familiar with application maintenance then it's easy to make parallel of code maintenance and application maintenance. Even if they are not the same, you can explain that the end customer here are developers or those how maintain the system.

  • 1
    Non technical people are familar with application maintenance? I asked my grandmother: she isn't ans she is the most non technical person i found. Additionally: Since a non technical person doen't know the difference between code and application ("If the code is the application, the application is code") your analogy won't work.
    – Martin
    Commented Nov 10, 2010 at 9:18
  • 2
    in the places I've worked, the marketing and projman types have understood "maintenance" to mean "bug fixes after release", and it'd be disingenuous to claim that refactoring is fixing bugs.
    – user4051
    Commented Nov 10, 2010 at 11:07
  • For me the non-technical person is the customer. If customer knows what application maintenance is then he/she should also understand code maintenance. Commented Nov 10, 2010 at 11:22
  • "Code maintenance" sounds like your code undergoes wear and tear or gets used up. A car needs to be maintained, because normal use stresses its components, uses up fluids, etc. An application isn't like that--code sitting on a hard drive doesn't "age" or "go bad" on its own.
    – Dan Ray
    Commented Nov 10, 2010 at 19:49
  • I’ll give you some example on maintenance: Performance issues. Your component, entire system or application is written in VB and Microsoft stop supporting it. The OS doesn’t support the technology your code is based on. Security issues. Maintenance on these issues doesn’t add any new functionality that the end user may notice, however they are critical for keeping “application” alive. Commented Nov 10, 2010 at 20:34

Say you are a mechanics that specializes in customizing cars, even building them from scratch if the customer requires it. There is this customer that is back in your shop every so often to always put some new shiny thing in his super-sized limo.

Once he comes in to have a nice sound system installed. You diligently perform the task passing wires and connecting it all properly. He goes out a day later, he is happy and pays handsomely, as usual.

The next month he comes back but this time he wants a full blown home theatre installed. Once again, you take the limo in. Being a professional you revisit the sound system and make it easier to maintain by installing a tubing system for running the wires around the car. This way the wires are protected and easier to pull out and should you need to add more will also be easy to do. So you rip the old wires out, install the tubing and pass the sound system and the extra wires for the cinema, close it all up and you are done.

Realizing that the customer did not ask you to replace the old sound system you scratch off some of the cost of the replacements and of the tubes. However you still make money from the deal, Just not as much as you would have had you just threw the system together like you did the first time.

One month later he comes back, this time he wants a lighting system and he wants new speakers having damaged the old ones earlier in the week.

Because you kept everything nice and tidy you can quickly run the new lighting wires through your tube, install the system and replace the speaker. This time however you are done much faster, the re-factoring paid off by keeping you on top of your game.

Your competitor who was laughing at you for ripping perfectly good wires and installing all this extra tubing is still struggling to get his customer satisfied. Sure he was done faster than you most of the times but as time goes his customers are complaining that there are more and more delays and the overall quality of the work is degrading.

Looking at this you realize that your goal to not only stay in the business but to be the top gun is to balance what you do for filling the customer's demands and what you do to make your life easier down the road. Very rarely a customer will pay for both so you have to manage closely. You gamble that by pro-actively doing things right even at the cost of doing things twice you will keep maintenance costs at a controlled stable percentage of your productivity.

Software is the same, except programmers can play with digital duct tape for a VERY long time before the effects are truly felt by customers and managers. Unfortunately by that time the cost of re-doing things right grows exponentially with respect to how much duct tape is present and the average age of said duct tape.

This is why it is important that we keep re-factoring the system. Very often experience will show us new more efficient way to do the same thing or we can combine similar functionality and exploit redundancies instead of just copy past them. This is how we keep the system lean and mean. Time will show that constantly re-factoring the system to meet demands will keep productivity constant by controlling the amount placed in maintenance.

Placing duct tape will momentarily increase productivity at the cost of carrying a sub-optimal system. Technical debt is incurred whenever immediate productivity is favoured in detriment of the other aspects of a system. The debt analogy is good because just as interests over borrowed capital eat away the profits the borrowed time making things quickly incurs higher maintenance and increase the system fragility forcing a team to spend additional resources in maintaining rather than creating. Just like its financial relative, if the borrowing continues unabated most resources are spent towards interest repayment leaving very little for improvements. Technical debt will eat away technical resources to a point where most resources are spent just keeping the system running grinding to a halt all other possible enhancements.

So ultimately the questions is not should we or should we not do it but is it ethical to let managers and customers believe they can rely on productivity figures artificially bloated with the use of digital duct tape. Some would think it is a business decision but quite frankly this is so just because managers do not understand it. In the end, someone will have to pay the debt either though heavy re-factoring or by migrating to a new system. It is ultimately to us, programmers, to keep systems maintainable, you should not have to ask to re-factor as it is an inherent part of the job, failing to understand this is failing to understand what software engineering is all about. This said, I realize there are systems out there that have incurred an important debt already and paying off this debt will require decisions from the payers. Your job is such situation is to at least do your part to stop borrowing. This debt was incurred BY US maybe because we did not know better, because we were pressured to do it, still, we took on this debt and very often the people we handed the debt to do not understand it, thus cannot manage it properly.

Here's your software, all done, hope you like it.... Ho by the way, I maxed out your credit card doing it, hope you don't mind... cya


The point of re-factoring is to simplify the design and remove inefficiencies. This makes it easier to fix bugs and add new features in the future.

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

If you continue to add new features to code, re-factoring will quickly pay for itself. This will be visible in lower error rate, faster debugging and quicker fixes.

  • But clever == 0 so 2 * clever == 0... Commented Sep 25, 2012 at 1:13

Writing software is a lot like writing a big non-fiction book, or an encyclopedia.

The first draft always sucks. It can always be improved by reorganizing it, removing sections that don't need to be there, and ensuring a consistent style throughout.

Whenever you have to revise, the simplest thing to do is just to add a new section, change a few words, and so on. But as the revisions pile up, the book starts to lose its organization. So you have to make further passes of reorganization. If you don't, the book becomes a nonsensical jumble.


Take your desktop computer for instance. You have a tower, monitor, keyboard, mouse, printer, scanner and speakers. Ultimately all you want is a nice organized desk. So you just plug things in blindly, and a few minutes later, lo and behold, everything is set up the way you want it. Well... almost the way you want it.

A day later when you are changing the balance on your speakers, you realize you accidentally put your left and right speakers in the wrong areas, so you want to swap their positions. But oh no! There is a jungle of tangled cords; when you proceed to move the speakers, your mouse cord gets hooked, and now your mouse gets dragged along with the speakers. Also, your keyboard now doesn't have any slack -- you used to be able to move it from the desk onto your lap.

Alright, you could just unplug the mouse and keyboard and reinsert them so everything is fixed. But this won't help with future reorganization and future additions. Also weaving your mouse and keyboard cords through the jungle is a hassle.

The better solution is to replug everything to plug them back in a neat clean way where each cord does not interfere with another. Now future changes are easy and continue to be easy. You invest a little up front for big gains later.

The key point is that the original solution mostly WORKED. That's the thing about refactoring: it works to begin with, but you need to change how things already exist to easily make future changes (moving the speakers).


It's kinda like cleaning up the house after a wild and crazy party from the night before.

Let's say the living room got totally trashed. The house is still a house, the living room is still a living room. It works but it's not the way it could be. After staring at the mess you realize that it needs to get cleaned up.

So, you start bagging the trash. It looks better already. So, you look around the room and decide to straighten out the furniture. You put one piece back, then the next and the next. Wow, the room looks really good. You are proud.

Your sister walks in and says the room looks like trash, you should fix the bookshelf and vaccuum the carpet. She's right. The room looks really, really good.

You look around and see that the window shades would look much better if they were all at the same height. Done. Wow, the room is amazing.

Treat your code the same way.

  • 1
    I like it, but I would change it to cleaning the kitchen. No cooking for a while, but things will be better afterwards. PHBs may have difficulty relating to having a party on company time :)
    – Jaap
    Commented Dec 5, 2011 at 14:11
  • Decent analogy, but there's one flaw that readers should be aware of: If you don't clean your house, then your house literally becomes less useable over time. Whereas with a program, this doesn't happen. Commented Sep 25, 2012 at 1:12


Take it with an example ... everyone has in their lives written a letter to a dear one. It has to be someone dear because in those letters we usually pay attention to composition as well.

So, you have your text, ... the meaning will go through either way, but you want the entire thing to sound nice! Right?

Refactoring, same thing ... same pieces of information, more or less, but the composition is better. And it will probably result in a better review by the reader.

Another example - writing an article for a magazine. Two writers, both know "their stuff", the only difference is one knows "how to write" and the other writes like he learned to write from answers like these.

Whose article will you remember?


All the analogies to things in the physical world -- like building a theater -- are, IMO, terrible.

You need to explain that refactoring code is like... refactoring code. Software is malleable in ways that physical analogs are not. As things get more and more complex, one must reactor (or redo, as you wish) massive or small parts of a codebase so that we can continue to increase the complexity without going insane.

Why do we refactor? Because code that is never refactored costs more per minute to maintain and change, and ultimately becomes more problematic.

What's so interesting about refactoring is that we redo the codebase but, at least at the outset, the functionality remains the same.

  • /All analogies/? I strongly disagree. You just need to be more creative. Also doesn't answer the OP's question. Commented Sep 24, 2012 at 23:57
  • @ThomasEding thanks for your comment. I disagree on the second point: I am, in fact, answering the question. However, I'll do an edit right now just for you. Commented Sep 26, 2012 at 0:17

Re-factoring is the same as cleaning up something and giving stuff a new place to 'stay'

Easy simple and something that can take a lot of times. Sometimes I even add that person X left a huge mess of things and I have to clean it up.


I thought of another example, which apparently no-one here has mentioned: refactoring is pretty much exactly the same as rearranging an equation in maths (though that might fall outside the scope of 'non-technical person, I guess).

When you rearrange an equation, you just 'move stuff around' to make it more readable and more usable, without changing the meaning.

  • 1
    so if I'm a PHB or customer (who is going to pay for this refactoring effort), why should I care? The code works (from my point of view) Commented Sep 26, 2012 at 21:02

Give them a simple math equation. For example:

Which is simpler?

y = x + x


y = 2x

Refactoring is a similar concept except instead of simple math equations, you put in algorithms. The main idea is that you can swap between two ways of doing things because they will yield the same result.

The simplest refactoring that can be done is renaming.

doX() { ... }

Now because we don't really want things to be called doX because we don't really know what it means, we rename it to something else that is more self explanatory and replace anywhere we have used it.

doBusinessTransaction() { ... }

This will save you money later on when there is a problem or enhancement because it reduces the time for people to understand and fix your application. To further save money, there are free tools that do this work for you automatically depending on what language you are using. These tools are also licensed such that it is not restrictive and would require you to do anything special aside from acknowledging it if you use it directly.


A picture says a thousand words. For example, refactoring has two use cases:

  • When things are not done right the first time:

refactoring when things are not done right the first time

  • When things are tedious:

refactoring when things are tedious


  • XKCD is it worth the time ignores the fact that making a routine task more efficient may well mean you end up doing a lot more of it than you would have otherwise. So you need to factor in the value you get from the extra performances of the task.
    – bdsl
    Commented Sep 19, 2018 at 19:14
  • @bdsl That's covered on workplace.se Commented Sep 19, 2018 at 20:01

Consider an answer given in Refactoring, and don't explain it to a non-technical person. Refactoring is a technical activity that they don't need to know about:

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

(Refactoring, Martin Fowler, 2000, page 61)

Of course this won't work if you're going to spend a month doing nothing but refactoring, but I think that's generally a bad idea anyway, and it's much better to just refactor to the extent necessary to make your current or next task easier, or to clean up code that you've just been working with.

Not the answer you're looking for? Browse other questions tagged or ask your own question.