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?

+48  A: 

It's not rocket surgery.

Paul Tomblin
+1 Yes! This is perfect, if the person has a sense of humor
+1 too funny! ... almost didn't get it.
John MacIntyre
How exactly would this convince anyone?
+5  A: 

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.

Konrad Rudolph
That was good, I've never seen that before :)
+10  A: 


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.

Steven Sudit
This is interesting, how do you "have user role-play the computer"? User can't exactly talk to the computer.
@Kugel: I don't mean role-play WITH the computer, I mean role-play AS the computer. The user should say things like, "Ok, if I was the computer, I'd be checking this ZIP code to see if it was valid for the country."
Steven Sudit

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?

I don't know ... that could kind of back fire with the wrong person. ;-)
John MacIntyre
+18  A: 

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"

+1 … good metaphors always play on things the audience knows.
Konrad Rudolph
Maybe not Federal Reserve... more like AIG or GM :)
ilya n.
I don't think any of our projects are actually quite that complicated... (That would probably take hundreds of years)
Jeff Davis
Yeah, it was a bit of an exaggeration but it gets the point across to the original poster. He should use an explain that matches, or attempts to match, the complexity of his application.
@ilya n - or Enron
Kelly French
+1 As a friend of mine in college used to say: A bad metaphor is like a Coke can...
Brian Postow
@Doomspork: I disagree. The point is that it shouldn't be an exaggeration, but relate the complexity in a realistic and easy to understand way. Otherwise, if you're not going to bother with that, then the discussion is moot; when the person says that you're "not exactly building the Sistine Chapel", you could just say "yes, I am" and leave it at that.
@Beska, I think you misunderstood what I was saying. My example is an exaggeration, but I encouraged the poster to use something that is similar in complexity. Since I don't know the complexity of the posters application in detail I can't provide accurate examples for him.
@Doomspork: fair enough. But I think that without explaining the metaphor, even a very accurate estimation is bound to fall on deaf ears. The metaphor has to make more sense, and the parallels will need to be obvious upon explanation...otherwise there is no gain over the the original "chapel" example.
@Beska, That depends on who you're talking to. Which is why I said it should be in terms they understand. An accountant could determine that it takes him 1 day to do number crunching on X number of dollars and the USFR does Y in dollars....
@Doomspork: that gets across the idea of how difficult and time consuming *you* think the project is, but the challenge isn't in coming up with a big metaphor...for that, again, people could just use the chapel. Even if you're not a painter, you can see it would take a long time and be tough. And they still won't believe you're not exaggerating. The trick is to come up with a metaphor that explains the *why* of the length and that the person can have some idea of the kinds of things that are difficult, and why they might take time.
+21  A: 

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.

Yes. This is the analogy we use often. Maybe more like an office building than a house, but the same ideas apply. (Infrastructure in the walls, interfaces on the inside, and public face on the outside)
Jeff Davis
+1 I like that. A house that grows and shrinks to the exact size you need it right now. A house that allows you to add external structures (add-ins) on the fly and have them automatically integrate plumbing and electrical. ... yeah, you can do a lot with that.
John MacIntyre
Jason Williams
Programming according to specifications is like walking on water. Not hard if both are frozen.
Software engineering is the only field where you will be asked to replace the basement.
A house is a great analogy - you can build it right now, quickly, but you'll have to skip critical foundation steps, and it will become unstable later if you do. The initial work (requirements, infrastructure) is like the foundation, and takes a good portion of the time, and even though the client doesn't actually *see* much happening during this period, it's vital to the success of the whole project. +1 to you, sir.
I was formally trained as an architect (the building kind) but work as a software developer now, so this metaphor always came naturally to me. The design/foundation/framing/finish part is apparent, and you might be surprised just how much a design changes midstream on construction projects - implementing your design always brings out new ideas and challenges. So even if the design stays unchanged, site conditions, building inspections, specific skills of your subcontractors, all contribute to decisions made on-the-fly. And just as in software, midstream changes can be risky - but advantageous.
+63  A: 

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

Developer Art
That's a fantastic anecdote, but it doesn't really answer the question.
+1 Great anekdote (for a surgeon) :)
@BenAlabaster: This is to the direction of systems integration - how to migrate to the other platform or merge the system with another one without users even noticing it.
Developer Art
it took me way too long to understand this one (for anyone else dense like me, I assume the complexity here is fixing it while it's running). I like the metaphor, especially if you consider "running" to be changing requirements.
@rmeador: I like this idea with changing requirements!
Developer Art
This is a bad analogy. There are no whirling parts that could take off your hand running at 1000 degrees in a human. Using anesthesia is akin to shutting off the car. Cars vary widely while humans are almost guaranteed to have the same anatomy.
@Unkown, the point of the analogy isn't the danger to the mechanic, it's the danger to the car. The surgeon is illustrating the fact that he works on a running machine that he must be extremely careful to fix and not damage.
@Unkown using anesthesia is more like putting the car in park. Operating on a human while they were awake would be like a mechanic operating on a car while it's driving down the interstate going 70mph.
@Joseph: until very recently all operations were done without anaesthetia. The surgeon strapped the patient down, filled him full of whisky and gave him a bullet or piece of wood to bite on. The point is, even under anaesthetic the engine is still running, the patient is still alive. You can't lift the heart out of the ribcage, disassemble it, run off the serial numbers at the parts shop and put it all back together over the course of a week.
This response, regardless of whether it is a good metaphor for a surgeon, *has nothing to do with programming project complexity*.
@Beska: Obviously you've never had to maintain a production system
@Beska: Integration with other systems as well as the following maintenance in live-mode belongs to the "programming project" in my book.
Developer Art
@Rotard: yes, actually, I have. And it would be a better analogy for that. But that's not what the question was asking. The question was how to give an idea of difficulty of archetecting and building a complex system...not maintaining a system without having to bring it down. Both are difficult, but usually for very different reasons.
+2  A: 

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

Carl Bergquist
I like that ... it communicates in their own context, but generic enough to use anywhere. It really explains all the bases which need to be covered. +1
John MacIntyre

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

I wonder whether you'll just end up insulting her than help clear things up if you say that about the building-an-outfit.
Jeremy Powell
Okay, that wasn't a serious answer - apologies if the irony was lost on anyone.
+1  A: 

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

Since I always know more about the software I'm developing then the client/sponsor, I ask difficult questions, like suggested. I'm usually pretty unpleasant about this, if someone with almost no experience tries to judge my efforts/work. For some reason people always think they understand everything there is about technology.
+26  A: 

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.

bill weaver
Maybe I should maintain a complete and comprehensive flowchart, which flows off my cubicle walls, up the real wall, and overflows onto the ceiling .... maybe that would get communicate it. If you drew a complete flowchart of a standard 100loc app, I wonder if the Sistine Chapel could even contain it all?
John MacIntyre
Awesome answer btw, thx. +1
John MacIntyre
Thanks. I think your side-by-side flowcharts are a good idea.
bill weaver
btw-In my comment I meant 100k loc app.
John MacIntyre
Oh, I think what we do DOES approach and even surpass the engineering of the Sistene Chapel. Have you ever seen it? It's a nice room. It's not even particularly large. The painting is beautiful, but the chapel itself is famous because of the fantastic mural, not because it was difficult to design and build.
This answer was accepted because it inspired the comparable flowchart thought. I honestly wonder if a flowchart for this app would even fit in the Sistine Chapel. And I think that would be the best metaphor.
John MacIntyre

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.

+1  A: 

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


I would agree with this, if the person followed up with examples of why adding programmers wouldn't necessarily help. Otherwise you run the risk that management will just think you're a wise-acre with a bad attitude.

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.

Steve Wortham
+2  A: 

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.

Travis Beale
+1  A: 

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

+60  A: 

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.

Hahaha :D That's outstanding, I LOVE it! I wish I could give this more than +1
Wow ... those parallels are just scary accurate! ;-) +1
John MacIntyre
Brilliant !! +1
Scott Vercuski
I would honestly +20 you if I could. Thats amazing.
Kyle Rozendo
That history degree sure comes in handy occasionally.
Justin Cave
+2  A: 

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.


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


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

+1  A: 

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.


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.

Chris Cleeland

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.

+14  A: 

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 ?

And babies are considerably more expensive than robots... and you only really find out if they passed all their unit tests when they marry the right guy/girl, start being successful and leave home. At least the robot has unit tests - presumably. I would think the robot would be abandoned *long* before the baby grew up and left home.
"automated lawn mower" - Yikes!
John MacIntyre
They have automated lawn mowers now. I suspect they work best on fairly flat and regular yards.
@Beska : They also have software in planes. ;) My point is : it's really really hard to implement. And you're right : they still need improvement to work on uneven surfaces.
@Silence: yup...I was just commenting to John, who seemed surprised by the notion. I've worked in the industry long enough to be very fearful of the notion of an automated lawn mower. :)
One of my friend was a in university competition of automated lawn mowing ( and a bunch of teams did really well. Don't be afraid, they know what they're doing... I think ;)

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.

+5  A: 

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.

I like the novel idea. Even more than the typo or grammar error, is that every detail would need to tie together to something else in the book without any conflicts. +1
John MacIntyre
+1  A: 

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.


+2  A: 

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.

Daniel Pryden
+6  A: 

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.

Norman Ramsey
Your first bullet is questionable. If you are building software you CAN and usually use pre-fab parts. The framework, Data Access, Libraries like JScript, OS level APIs, etc.

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.


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

Karl Anderson
+1  A: 

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.

Bryan Watts
+1  A: 

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.

too much php

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
Keith Williams

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.


+1  A: 

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.