How to explain bad software to non-technical people?

Question

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?

EDIT:

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.

Answer 1

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

Answer 2

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.

Answer 3

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

(from Wikipedia page)

Answer 4

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

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

Welcome to the wonderful world of the project manager. All the responsibility, everyone telling you what needs to be done, little to no power to make it happen.

We have our own analogies as developers, and sometimes they translate well to describing something you want them to let you do: "this code is a house of cards; it looks nice now, but there are several places where if you just blow on it, or if you put one more card on top, the whole thing will crumble into a big mess."

If it's a speed issue, talk about speed. "This code is written in such a way that the number of steps needed to get the result increases on the square; 2 items would take 4 steps, but 5 items would take 25 steps, and 100 items would take 10,000 steps. You want this piece of the software to be able to handle thousands of records; you could wait for hours or even days for a result. We can rewrite it to take seconds."

If it's security, talk security. "We found a way that someone could get into our system and view your information. We need to solve the problem, but it'll take some work".

I think you'll find that as long as you don't start sounding like a programmer, using technical terms and jargon they don't understand, most humans in management are smart enough to get it. If they're not, well, maybe you should be updating your resume.

Answer 10

Sometimes wikipedia can help:

• Technical Debt
• Big Ball of Mud

Answer 11

How about extending the house metaphor a bit, e.g. "shoddy wiring that needs to be replaced before it causes a lot of damage"?