An analogy for software development I've heard is to imagine building the Empire State building but with your view limited to a 15" glass portal. You must remember the off screen portions of the "building" in your head.

My current favourite is to describe it like this: You have to build a puzzle. Problem is nobody really knows what the puzzle should look like. Instead you get a few hundred pages of documentation written by a bunch of people who don't really know much more about the puzzle than you do describing how they think PARTS of the puzzle should look like in the end - based on discussions they've had with people who have no idea about the big picture either. Oh, you don't actually get any puzzle pieces - that's up to you to create.

As you start trying to build something that looks like the puzzle, you realise that instead of the 1,000 pieces originally estimated for the puzzle, you're going to need 5,000, and the puzzle is actually in 3 dimensions not just 2, and also the puzzle needs to fit with another puzzle built by a different team of people who had no idea your puzzle needs to fit with them. Then you find out your puzzle pieces, that you borrowed from someone else, don't work as expected with put together with certain other pieces... :)

I always liked:

Your supposed to design a 4 lane bridge for a new interstate, you say sure that takes 6 months where do you want it?. After 3 months they decide where they want it and expect the design in 3 more months. You say, that's not going to happen I might be able to pull 5 months though.

So, assuming you know where it's going to be you start pulling in some overtime and get to work. After another month they say, we need a 6 lane bridge, after another they want to add a train. And 2 weeks before the deadline they decide on a tunnel. SO, you end up submitting a 6 lane bridge design that can't handle trains.

Which is why software is always late, and you don't hand them what they want.

I like this analogy as well as the analogy you replied to simply because they relay the massive velocity of change we have to face.

You got documentation to start from? Lucky bugger.

That's it. I'm puzzled.

This is very true. Explaining systems of reasonably small scale seems hopeless to non-developers sometimes.

However I think this is true of a lot of fields... some people just can't grok (and don't need to grok) how an automatic transmission in their car works. I'm particularly inept when it comes to the subtleties of art and music.

But a particularly relevant analogy that I use would be that you are working at a library. (That is: a library where you can check out books, not a software library.)

Not only do you have to write a good portion of these books, but you also have to read a lot of the books in the library, and at the very least you have to read the table of contents and/or index of most of those books.

In addition to this you have to be very good at keeping the library organized, and you have to coordinate with other staff members at the library.

Smaller systems are simply a shelf or two of books, larger systems can span several buildings.

I like this analogy because most everyone can relate to it, it gives a very real physical sense of size, and I think it pretty adequately describes what a programmer has to hold in their head on a daily basis.

Heh. Early on in my software education, I asked a friend of mine about the difference between real time systems and normal. He said, "In real time systems, if something goes wrong, the Space Shuttle blows up." Seems like an apt metaphor.

no need for the drama. realtime simply implies there is known, hard maximum time it will take for certain in-scope operations to take place, so you can design around that. a realtime os will often be slower overall than the non-realtime os on the same gear. the bottom line is about predictable, knowable behaviour.

challenger blew up because of a fuel leak, not the lack ofi an rtos.

Why would they have to understand? Do you understand the intricaties of an airplane when you fly one?

I can at least understand it takes a bit of engineering to heave a nearly million pound piece of metal in the air. Twitter just doesn't have the same cachet. Hell, it's only 140 characters, how hard could it be?

I don't think Twitter is an adequate comparison. Even within the developer world you get plenty of programmers saying Twitter is a "weekend toy project" to implement. (And in many respects it is, for the functionality--the more interesting bit is handing the massive user load.) A more apt comparison may be with the Linux Kernel, or Windows 7.

I'm not suggesting one needs to understand the intricacies. I understand that aircraft are extraordinarily complex, and that's sufficient. I get the impression from non-computer people that software development is the equivalent of typing a Word document, except with mono-spaced fonts and highlighting, and lots of typos leading to bugs.

When people have a view of software development like this I usually retort by pulling up the Wikipedia page of a modern processor.

For instance right now I'd probably pull up the page for the Intel Core i7 and show them the transistor count.

I say: "You're now in a room. It has <transistor count> light switches. I write the instructions that tell you precisely how to flip those switches. You have <cycle time> to perform each instruction. Also it takes <x> instructions to <do some useful unit of computation>"

It's a bit exaggerated, of course, but it usually shakes their view of computers up a bit :).

Airplanes are usually come up when people are asked for an example of a complex piece of engineering. But rarely do they realize that most complex part of a modern airliner is the software.

"People" dont have to understand. Unless they are legislators trying to write new laws to govern "x", then they MUST understand.

Because they need to understand medicine when they make drug (the prescription kind) or other medical related laws, or chemistry when they make environmental regulations? Please. Only a superficial understanding of technicalities is required to legislate sufficiently effectively, understanding that can easily be supplied by staff who make high-level summaries.

They don't have to have an intricate understanding of medicine, but they should understand the issues well enough to be able to make informed decisions. If they do not understand, then they should bring in experts. For example, if you want to make legislation regarding a certain vaccination, then you should understand how vaccines work at a high level and the concept of herd immunity. Otherwise, you have no business writing laws to regulate it, period. The people writing this legislation don't have an equivalent level of insight into how the internet works.

In this video, we had a lot of people proudly proclaiming that they didn't have the slightest clue about how the stuff they were regulating works, made terrible and inaccurate apologies, all without bringing in experts who could inform them as to the implication of the law. To add insult to injury, rather than calling them experts, they used derogatory language to put down the very people who knew what they were talking about (lets be clear here, some people use nerd as a badge of honor, but that was clearly not how they were using the word).