Are there any good metaphors for explaining project complexity to a non-programmer?

Question

It was just mentioned that I'm "not exactly building the Sistine Chapel." This is true, but I am building a freight management application, which isn't exactly as simple as drawing controls on a form (even though the vendors would have you believe it is).

I don't hold this against the person who said it, but I do feel the complexity of what I'm doing is a little misunderstood, or that statement would not have been made.

Are there any good metaphors which might illustrate a project's complexity to non-programmers?

Answer 1

It's not rocket surgery.

Answer 2

I can't help myself, but I just must post this video from That Mitchell & Webb Look:

Brain Surgeon - That Mitchell & Webb Look , Series 3 - BBC Two

That out of the way, it might help to demonstrate that planning a software project involves many of the same problems as planning the construction of – oh, say, a chapel. You've got a lot of very different aspects to manage and if someone makes a mistake at the very basis, the whole think would break down.

Answer 3

No.

Honestly, there aren't.

The best you can do is have the end user role-play the computer, so that they have to think through each use case until they realize how innately complex the process is.

Answer 4

maybe you can not tell why it is complex but you may reference labour on complexity.

you can tell that it is so complex that 10 people should work on this project 2 years?

Answer 5

A metaphor won't do you any good if the person doesn't understand it either. You should try to explain the complexity to the individual in terms they can understand. If possible try to relate it to a complex work situation they might experience.

For an accountant you could say something like: "This is like you taking a calculator and auditing the US Federal Reserve by yourself"

Answer 6

If it's not like building the Sistine Chapel, maybe it's more like building a house. Lots of different things go into building a house, with lots of different people involved with different specialties. Nothing is overly complicated, but there's a lot of work involved!

The problem is its really not like building a house; it's more like building a house that changes all the time. For the purposes of complexity, though, this might illustrate your point more effectively.

Answer 7

I would recollect an old anecdote I once heard:

An auto mechanic asks a surgeon: "Why do you earn that much? What could you possibly be doing that complicated? My work with engines looks very complex and challenging to me, and I'm real good at it! I can fix anything that is wrong with an engine!"

The surgeon then goes over, turns the ignition and starts a car. Then he looks at the mechanic: "Well, now fix it."

Answer 8

The main goal of business application is often to help communication within an organization. So when I'm trying to describe the complexity of a business application I often tend to break down some daily business communication between person X and Y. And pulverize it!

This makes it easier for the person without any programming experience to relay to the complexity. Cause not only do you have to make X and Y talk, you also have to make up their language. etc etc.

I hope this will help =)

Answer 9

The building-a-car analogy almost always work. Know your audience though as it might not be one for the ladies (try building-an-outfit-that-co-ordinates analogy instead).

Answer 10

Let the other person speak and ask difficult questions. Might also be a valid strategy. On which figures is his opinion based on?

Figures are more easy to understand.

Do you have a number of

• List item
• use-cases
• requirements
• involved developers in similar projects
• companys or needed third party products
• user
• sites
• ...

Do you need synchronization? Also good point to find metaphers.

Is there a risk managment? What is the impact of failures. A standard PC programm is not critical, but what happens if your program computes wrong values or does not work anymore?

What is the difficulty to programm an OS - I know how to use it :) Not a valid answer, right?

Good luck

Answer 11

Some metaphors...

• Complexity-wise, it's kind of like building a car, or boat, from scratch, by yourself. Software projects that require a team of engineers are like building the space shuttle. The only difference being that if you foul things up, people don't usually die. If peoples' lives are at stake, it's even more like the space shuttle. (Software is almost never as cool as rocketships, though.)

• It's true that your software project isn't the Sistine Chapel (what is?), but it is kind of like building a freight management system, which is itself incredibly complex. You could draw some diagrams on a whiteboard or happen to carry around system design and dataflow diagrams. Help them see.

• Ask, "have you ever built a computer?" Selecting and ordering all the components, building the computer, selecting and installing operating software, device drivers, configuring the final result will all take less time and be far less complicated than this freight management project.

The advice about relating it to something they do is good, but make sure you understand enough about what they do to make an adequate analogy. If they're a trained mechanic and you said it's comparable to rebuilding a carburetor (instead of, say, an automatic transmission), they might think "okay, so it's not very complicated."

Neil Ernst talks about software metaphors a bit, applicability of the home contracting metaphor, and also makes the points out that software engineering is inherently hard to explain because it is work in the abstract.

Neil links to an essay by Jim Waldo, Software Engineering and the Art of Design, in which he points out

In this way, what we call software engineering is really more like architecture (real architecture that produces buildings) than it is like other kinds of engineering. There is an element of science (a building has to obey the laws of physics) but there is also a large element of art. Depending on what kind of software you produce, the mix of the two may differ some, but there is always a mix.

So, perhaps grand architectural and building feats are an apt metaphor. (Not that what we do comes close to the Sistine Chapel, but we should approach what we do with that in mind.)

Unfortunately the person who dismisses your project as trivial is unlikely to understand this. They might not be able to think abstractly enough to get it. The best you can hope for is that they kind of grasp the car or boat or house analogy, or maybe help them to see it with diagrams.

Edit: You made a point about the relative complexity between your project and "drawing controls on a form." Perhaps you could respond to the Sistine Chapel remark by saying "that's true. However, if a three month web project is the small shed behind your house, this freight management system is Rogers Centre.

Answer 12

I might avoid the house metaphor. When we built our house 3 years ago, we were aghast at how unlike an engineering project it was. I swear the plumber and one of the trim carpenters must have been drunk.

Show this guy your functional specs. He'll start to get an idea of how much detail is involved in building the application.

Answer 13

When you deliver the project late due to lame project management producing unrealistic estimates ... then the powers that be say

"If we add a few more programmers to the project do you think we'll get it done in time?"

You can reply with

"My wife is having a baby, the doctor said it will take 9 months, I asked if we used another 2 women we could get it done in 3?"

Rich

Answer 14

Programming involves a plethora of conditions and actions layered on top of eachother. If one condition isn't 100% correct then the program may perform the wrong action. And computers are not forgiving.

Much like a master chess player anticipating his opponents moves, it's the programmer's job to anticipate every scenario and account for it in code.

As the project grows, the chess board grows and the necessity for perfection becomes exponentially more difficult for a single programmer to handle.

Answer 15

You can compare to previous software projects.

Remember that old project X, and that it took about 6 months? Well, new project Y is roughly that complex.

Failing that, compare your project to other projects that require real-world, physical engineering. Some projects are like designing and building a house, some are more like a bridge.

It's even better if you can find engineering projects that your company has done as a basis for comparison, of course this depends on their industry.

Answer 16

just be thicker skinned. unless it's the boss, you don't have to explain anything. and, btw, you will never get it through to people who think you spend all day on the Internet (how, ironic). This goes for programmers, server people, and so on.

Didn't you know that you did nothing for a living?

edit: I got a down vote with no reason...

Answer 17

The speaker almost certainly really meant "painting the Sistine Chapel [ceiling]". Are there any meaningful parallels?

Michelangelo had some problems with the scaffolding suggested by the original architect. He ended up constructing his own framework.

Michelangelo was a sculptor and he had to learn fresco painting in order to complete the commission.

Pope Julius II originally wanted 12 figures painted, of the apostles. Michelangelo negotiated a free hand in choice of subject matter, and delivered Old Testament scenes depicting over 300 figures. He did all the painting himself.

The project continually ran out of money(because the Pope kept waging war with the surrounding states).

So let's see. Heavy dependency on a technical prima donna, cashflow problems, not delivering to the client's specifications... You're right, it sounds like no software project I ever heard of.

Answer 18

I think it's common that people who lack a technical background oversimplify what we (meaning programmers) do. That said, I think many programmers overcomplicate what we do, or at least make a bigger deal of it that it really is.

I'd venture the software that most of us write isn't really doing anything that complicated (Before you get in an uproar I freely admit there are many, many excpetions to this). We love to throw around metaphors to building a house or office, where the client is constantly changing his requirements or has ones that are completely at odds, as if that was unique to our discipline. Well, if you told that story to most contractors I suspect they'd laugh in your face. They are no more immune to contradictory requirements, non-sensical requests, and changing demands than we are. A pure 'waterfall' approach has no less issue with it for them than it does for us.

So, that out of the way, the best way to help a non-programmer understand why a particular task or project is difficult isn't, I think, to come up with some metaphor. It's to involve them. Show them an example of something trivial and give them insight into how much work actually has to go into that "trivial" change.

If you have unit tests, maybe make a one line test and then show them the results of your tests before (which should all be passing), and after with red bar after red bar. "There, you can point. Look at everything that one line of code broke. I have to go fix everythning there". Of course, that's a concocted example.

I don't think an analogy will ever give a non-programmer true appreciation for the complexity of what we do (with the caveat that really, it's not that complex). You have to really give them insight into the actual work you're doing, which actually take a lot more critical thought that a simple, clever analogy.

Answer 19

In an interview, I remember Moby saying something to the effect of...

Sometimes I think that I should rephrase "Everything is wrong" to "Everything is complicated."

---

That's software.

Or they actually read, give them:

I Sing the Body Electronic: A Year with Microsoft on the Multimedia Frontier, which is probably the best book I have read that could give a lay person insight into software development. (In fact, as a non-CS major, it was one of the books that lead me to stay with software).

Answer 20

On some projects I feel like trying to fit an octopus into a small box. And with some projects I feel like I am assembling a jigsaw puzzle made of a running movie. Probably not the metaphor for explaining something to a client, though :)

Answer 21

Everyone understands McDonalds. If you have a whole bunch of cash, you get a franchise and someone comes in and sets the whole thing up for you. Software is like getting the franchise and then having to do everything yourself...

1. Find property
2. Bid on property
3. Buy property
4. Get a construction crew to build a shell building that looks like other McD's
5. Find and buy necessary equipment
6. Install equipment
7. Get computers
8. Write point-of-sale software
9. Put computer at drive-up window and write code to xmit orders to burger flippers
10. Write time card software
11. Write payroll software
12. Install and computerize security system
13. Hire competent crew
14. Train crew
15. Buy stock
16. Write software to track stock
17. Write software to anticipate orders of stock
18. Etc.

You get the idea. There is a lot of stuff that goes into development that the average Joe doesn't realize. McDonalds appear like magic. But there's a lot that goes into getting (and keeping) one running.

Answer 22

The first question I would have is who is your audience? Is this management? Why does it matter that this person understands the complexity?

Presuming that it's business-critical that this person has a moderate grasp of the complexity of the system, you could take the tack of showing an overview of the system, getting into the detail of one aspect, and then asking their input on where the system could be simplified. It's also possible that this person truly has a unique aptitude for understanding your complex system, so to them it really isn't complicated. Regardless, getting them involved and invested in the system's development and they may turn from being your harshest critic to your champion.

Answer 23

The problem I found is that sometimes simple things are a lot more complex than imagined. For example, they could simply say, "Everytime this happens, make it do this." And it's simple changes, but ends up requiring a lot of codes or complex/buggy behavior.

To explain it, it's a bit complex. If your project manager is giving you a tough time because it's simple to him, then what needs to happen give it time. Say it's not ready, then show what you have. Eventually they'll learn that when you say it's going to take X amount of time, that you really mean it's going to take X amount of time.

Answer 24

Programming is like teaching a baby. Bear with me on this : Imagine you want to explain to a baby how to go shopping for carrots. You will do the same thing as teaching a robot.

First he has to learn to walk. Walking subroutine. I won't go into details but he must place a feet in front of the other and balance his weigth. You have to manage the exception where he falls or is confronted by an obstacle.

Then he needs geographic specification on the location of the super market.

He must be told to use the walking subroutine until he finds the market. If he doesn't find the market in a reasonnable time (must be defined), he must initiate the return home routine.

If he finds the supermarket he must locate the carrots using the carrots reconnaissance algorithm. He must compare every object with the carrot 3D model from his databank. Reasonnable time again (or timeout).

Then he must evalute a place to trade thoses carrots with money to gain permanent access to the carrots. This part could be real tricky.

Then he must evalute the price based on current carrots internationnal pricing versus the ressources needed to obtain lower priced carrots at another location.

I'm only half way through the process and you catch my drift. And I skipped a LOT of checks and exception, evaluation, recognition, etc. It would take months, maybe years, for a full team of developpers to program this. And it only goes buying carrots.

What I'm trying to say is that when you are developping an application, you have to "tell" it everything, literally everything. For every detail that is not clearly specified, you will have surprises : "random" behaviors, errors or simple shutdown. You have to tell to the program what to do in a general situations and how to adapt when the situation changes. Programming is like teaching a baby a very very complex task.

Then comes the worst part. You can't hold the baby's hand through the whole process. You make sure he has everything and let him go. 2 possible outcomes : everything works fine from beginning to end as expected (never happens) or the baby is sitting down somewhere in the middle of his task, crying, and you can't ask him what went wrong. He's just crying and won't stop. And then the debugging begins.

Now you can better imagine how much efforts is needed to build a software that manages stocks exchange, or an automated lawn mower, or a plane ! How much time would you need to teach a baby how to pilot a plane ?

Answer 25

I like to say it's like building a ship and then maintaining it: keeping the engine in good order, cleaning, scraping off barnacles and things like that. Of course a software doesn't break because it's old, the requirements change, the environment change.

Take a look at Steve McConnels's Code Complete, you'll find some good metaphors in there.

Answer 26

Scroll through the thousands of lines of code really quickly for them. Say "If one character is wrong, this whole thing won't work".

Another one:

Its like writing a novel except if there is a single typo or grammar error, the whole thing makes no sense.

Answer 27

Back in 1982 I was designing some new test machine core electronics for Intel. It was for testing of micro-controller chips (8X4X family of micro-controllers). I was asked why it was taking so long by a guy in product engineering (I was in test engineering). But the question had an attitude behind it. I was only one year out of college at the time.

I asked him , "Have you ever designed a test machine?"

He quickly realized the problem with his question.

Hope this helps.

JR

Answer 28

This is one of my favorite metaphors to describe software engineering:

• Imagine you're building a house. You'd have to have plans for the house, and decide what materials to build, and how to organize the building process. (Most people have had work done on their house so they have some rough concept of what's involved in this.)

• Now imagine that you're not building a house, you're building a skyscraper with 100 floors of offices. How would the plans be different than the plans for the house? How would the materials need to be different? What factors would need to be carefully considered?

• Now imagine that you're not building the skyscraper yourself, you're building a robot that will fly to the Moon and build the skyscraper there. Now how would the plans have to be different? How would the materials need to be different? Do you see why the ramifications of every decision would need to be carefully thought through?

You could replace "skyscraper" with "freight management system" if you wanted, and I think the metaphor would still be useful.

Answer 29

A metaphor I often use with lay people is that building software is not like building a bridge:

• If you're building a bridge, you can buy I-beams and rivets, and you can pour standard concrete. If you're building software, you have to make your own I-beams and rivets, and you may have to invent nonstandard concrete.

• When the bridge is half completed, nobody tells you that it should function at night as a drive-in movie theater. But in software, late-breaking change requests are common.

• You can tell when a bridge is half completed. You can't tell when software is half completed.

• By using X-rays, ultrasound, and other tools, you can be sure that a bridge is free of structural faults, before the bridge is ever used. But even with best practices in testing, many faults in software cannot be discovered until the software is used. And it is very difficult to know how long it will take to correct a particular fault or when the last important fault has been discovered.

All of these factors help to explain why it is difficult to predict how long a software project will take, and why software projects are often late.

Answer 30

I'd take the house-building metaphor a bit further. Each project is like building a house from scratch using slightly different components whose materials have different properties and who interact with each other in different ways. Often, each house is built on a different planet under slightly different physical laws.

And of course there's the ever-present customer who keeps changing the design of the house as you're building it.

So yes, you can say that all houses are the same; roof, walls, doors, windows, plumbing, wiring - but the Devil's always in the details.

How about an anti-metaphor? A software development project is NOT AN ASSEMBLY LINE.

Answer 31

I tell people it's like maintaining an engine which needs to be kept running and will be doing a different thing each week. Also, it's invisible, and you have to figure out what's going on indirectly.

This description doesn't really satisfy non-technical people, but it helps me feel better.

A good part of engineering complexity involves interactions between people (and the divisions they represent, and their goals, and the evolving design decisions that come out of these interactions). I've never been able to explain this to non-engineers, who usually tell me, "you could just work from home all the time if you wanted".

Answer 32

Writing a software system is like writing a story. It is a creative endeavor whose coherence is directly dependent on the writer. As a story progresses, plot points (requirements) change, and characters are introduced, shaped, and cut as necessary (refactoring). The understanding of the story (domain) is ever-evolving, and certain details just can't be known until relevant portions of the story are actually written.

Code is an expression of ideas; a developer thus has more in common with being an author than being an engineer. As has been mentioned in other answers, the analogy of building a house (or car or bridge) isn't up to the task. We as a people have been hammering out those patterns for centuries; we've only been developing software for ~60 years (as an industry for ~25). If mechanical engineering were a solid analogy for software development, we wouldn't have the problems we do with estimates.

Answer 33

Talk them through all the logic you had to program in for the edge case scenarios.

For example, they think that the report on Number of Contains Shipped is pretty simple, because they just select a date range and a number comes up. Tell them about how the code has to look for containers that haven't reached their destination yet, it has to check that the containers weren't returned to sender, if the container was held by Customs because it looked suspicious, then you have to connect to a Customs Office web service to check on the status of the container, you need to ignore containers that were cancelled, containers that were lost at sea because a ship sank are counted as shipped, but only if the ship sank more than 120 nautical miles off the coast of the USA, UK, France, Japan or China, or 30 nautical miles off the coast of any other country, containers destroyed during a traffic incident are counted provided the driver of the truck was not at fault, containers that just plain went missing are not counted until they have been lost for at least 6 months, and so on.

This gives people an idea of the overwhelming number of 'minor details' which a programmer has to account for, even in apparently simple programs.

Answer 34

It's a garden. My mother is a keen gardener, and she talks about her garden the same way I talk about my codebase.

1. It's never finished - there are always weeds to be removed (bugs/refactoring), and plans for new herbacious borders or a vegetable plot (new features/requirements)
2. You have to cope with the unexpected - one day, when she went to weed and re-organise a flower bed, she found that a colony of frogs had taken residence, preventing her from doing anything intrusive until the winter (bit like finding wierdness in a 3rd party library, or waiting on an external contractor)
3. You can waste your entire life in it, and never feel like you accomplished half of what you wanted to do

Answer 35

My approach is totally different:

I simply explain to them as if they were another developer, when they ask what a techinical term means,I explain that too, which usually leads to even more detail, etc. I've found that users then actually realise just how complicated the affair is.

In my view analogies will not work, because they have no way to relate back to developement.

Darknight

Answer 36

I like to compare programming projects to airplanes. There is a wide range of complexity in aircraft. A low-level, simple but functional app may be a WWII biplane. It’s got limited use but in the right context it’s the right tool. On the other hand when you start looking at a commercial jet liner and the level of detail/complexity needed to build one you have an entirely different story. Not only does it have to be able to fly the people using it need to be safe and comfortable while using it. If the plane (app) crashes or has excessive delays the passenger (user) gets frustrated/dissatisfied. If it happens enough they’ll find a new airline. You can run with the intricacies of the plane along whatever path you need.

The other massive difference in the planes is the skill level and number of people needed to fly/maintain the aircraft. One man can fly/maintain a biplane, but you need a larger crew with more training/man hours to deal with a commercial airliner.