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!)
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...
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.
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.
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
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.
"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:
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."
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.
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.
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.
Easy!
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.
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.
Give them a simple math equation. For example:
Which is simpler?
y = x + x
or
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() { ... }
{
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() { ... }
{
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:
References
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.