Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In discussing software development with non-technical people (customers, business owners, project sponsors, etc.), I often resort to analogies and metaphors. It's relatively easy and effective to use a "house" or other metaphor for describing the size and complexity of new development.

However, we often inherit someone else's code or data, and this approach doesn't seem to hold up as well when trying to explain why we're gutting something that already seems to work. Of course we can point to cycle time and cost to be saved in the future but this generally means nothing to business folks.

I know doctors can say "just take this pill," but I'm not sure that software devs have the same authority. Ideas?


Let me add a bit to the discussion. The specific project I'm talking about has customers that don't realize (or care) about specific aspects of the system we're retiring (i.e., they think it was just fine):

  1. The system would save a NEW RECORD every time someone updated a field
  2. The system contained tables for reference data. These tables had new records added every day, even though they were duplicates of previous records. And there was no way to tie the reference data used for a particular case at the time it was closed. This is like 99% of the data in the old system.
  3. The field NAMES also have spaces, apostrophes and other inappropriate characters in them, making everything harder to work with.
  4. In addition to the incredible amount of duplicate data, they have around 1000 XLS files with data they want added to the system. Previously, they would do a spreadsheet for each case in the database, IN ADDITION TO what they typed into the database.

Getting rid of this old, unneeded information and piping in the XLS data comprises about 80% of the total project effort, and was not something we could accurately predict. I'm trying to find a concrete way to describe how bad this thing was, mostly so that the customer will understand why the migration process has been so time-consuming. The actual coding was done pretty quickly and the new system works fine, but without the old data they won't be happy.

Sorry to get into the weeds, but most of the answers I've seen so far are pretty basic scope/schedule/cost things. I've been doing this for 15 years, so this really is more of a reflective, philosophical question - but without some of the details it can be difficult to really appreciate the awful beauty of this problem.


migration rejected from Oct 8 '13 at 22:13

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by gnat, GlenH7, Giorgio, MichaelT, Robert Harvey Oct 8 '13 at 22:13

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Business folks don't understand future cost savings? – Travis Gockel Mar 4 '11 at 16:01
Doctors don't have that authority. It's called "full disclosure." – Michael K Mar 4 '11 at 17:57

That rusty gas pipe in San Bruno which had been delivering gas safely for decades, but wasn't inspected, replaced, etc.

Then it blew up and killed a half dozen people in the neighborhood.


House owners are frequently familiar with things like "unsound foundation - the building may come down", "water seeps into the cellar" and "dry rot".

Especially "dry rot" may be a stronger, usable alternative to "technical debt":

enter image description here

(from Wikipedia page)

+1 for the egg sandwich picture – Alison Mar 4 '11 at 17:05
@Alison: thanks, I need a bucket now... – Matthieu M. Mar 4 '11 at 17:58

Convert your examples to something they can understand: Application speed, maintenance/upgrade costs/time, incorrect data, unknown errors, etc

For example, I was asked to update a report. It was a horribly inefficient thing that took 5-10 minutes to run because it had badly written queries and would recreate a huge, unindexed temp table to pull the report from. They didn't need to know that. They just needed to know that if they let me have a little extra time to work on the report, I could recreate it completely and make it so they could access their report on demand instead having to wait 10 minutes to get their data.


In this case I wouldn't resort to a metaphor. I can understand the situation you are in, and it can be difficult. However, I found it best to be very to the point, using real world examples and comparable statistics.

The way you explained it in your edit is really a good start, because you actually listed certain problems with the data quite clearly. If illustrated with real examples and the scope (how many records are affected) I think you have a good start. For example, just explain how much space you need when every change is recorded as a new record - for years and years. (Ok, I'll throw in a metaphor anyway: think about mailing around documents that are reviewed and adapted by various team members, and the exploding mail box sizes when you have ten copies of the same document.) Do illustrate with actual numbers: how many records are redundant, what time intervals etc.

Also, take a look on why the customer came to you in the first place: if they already mentioned they wanted more consistency for example, don't hesitate to underline how this will improve consistency. If they wanted to streamline procedures, explain how that is exactly what you are doing.

Another reason to really be very specific with the customer is to let them set the priorities. For example, I know that with certain data clean-up, records older than 5 years mainly needed to be filed: not thrown away, so they could be recoverd if needed. But it didn't need to be categorized to the new system, since they were not actively in use, nor did they show up in reports. The customer decided it wasn't worth the cost to precisely match it, and was satisfied to categorize them as 'old record'.

(And that might be exactly what happens with the 'new record'-situation, because it is a way of logging history. Let them decide wether they want you to log all history, compress it, or throw it out completely etc.)

And, on a more practical side, it really helped on certain occasions to keep the old data intact. For reference, but also to clear up conflicts about what was actually in the old system. (For example when certain numbers didn't match, I could show them that the previous calculation was the one that didn't get the results they expected.)

Okay, fair enough. Now the customer says "So what? What's wrong with saving 20 copies of my case? Oh, and you better bring me the right one when I want it." I'm not saying that I haven't been very successful at bridging the technical/business gap in the past. What I'm looking for here is how others deal with the most technically-DEclined 5% of customers. – mtutty Mar 4 '11 at 21:17
The scenario you mention doesn't seem to be about bridging the gap between technical and non-technical, but more about bad expectations and communication at large. When talking to people who are willing to communicate with you about solving matters, I've found the above to be sufficient. If the customer however isn't interested in communication and just expects some heavy magic for cheap prices, no great metaphor will make them get it, because they just don't want to. – Inca Mar 5 '11 at 12:51

Imagine the code is a car engine, some engines are easy to tinker with and enhance other make it really difficult to make changes or enhance the engine.

Also a car without a catalytic converter works just fine, but if you replace the exhaust with a catalytic converter you reduce your emissions.

The breaks on your car might stop it even though they are worn out, but if you want to stop on a dime you need to get better brakes.


As long as you use the metaphor correctly you should still be able to use the house approach. When using metaphors you just have to make sure that you use an example that both parties are very familiar with that can be related well with what you're trying to explain. It was mentioned before that you could use the example of bad wiring... if you explain that leaving this would likely cause a fire or something then that suddenly makes it a much more pressing matter. You could also talk about poor shingling (water leaks = further damage and repairs), bad piping (i.e. rusting, cracking, leaking = lots of damage if not flooding and huge repairs later). And if the company wants to expand later you could also explain that the underlying structure isn't expandable with out significant rework and attempting to "knock down a wall" to expand the "house" would likely result in a collapse. These are things they likely will understand. If they have any wits about them at all they should realize that its to their advantage to let you rework the insides.


I think we try to tell clients too much. They have a request and all they want to know is: Can you do it? How much will it cost? How long will it take? In our mind we turn the questions into: Why is this so complicated? Can you justify your fee? How can you lower my expectations and extend the due date?

Of course we want to give the true answer, but it is difficult to exclude the technical jargon. After your third sentence you notice they are lost, so you bring up the House Analogoy. The manager tells the CFO that it will cost more because of "tight couples" that are like English wall sockets.

Every house I've lived in with every repair person I've hired I'm told the previous work in my house was all wrong. Always, the wiring, plumbing, heating, roofing, kitchen cabinets, chimney (I've owned a few homes.) were done poorly.

In our industry, maybe we just hear about the horror stories. Could be that no matter what, the other guys code is just going to suck on a certain level. Sort of like trying to complete someone else's novel.


I recently inherited a very bad software and when I had a discussion the other day as to why bug fixing took so long and why implementing new features took a long time, I found they understood it best when I used a wired brain terminology. "Fixing a bug in your software is like poking around in the brain because that's how your software looks like analogically. If I work on a nerve, it might fix the problem directly and cause others or it might be that I break some part of the body of the program because that nerve was wired into other nerves and I have to trace every connection". Needless to say, after that explanation I stopped looking like a lazy programmer, (Well to them anyways) :)


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