Explaining Complexity in Software Development?

BMazurek asks: "I'm stumped by how to explain software development complexity (not theoretical big-O notation, that's easy) to non-developers. When it comes to people who aren't in the code, my explanations fall flat. It's not that the people I'm talking to are stupid, they're quite honestly people at the top of their respective (non-tech) fields. How do -you- explain software development complexity to non-developers? What analogies do you use?"

"I often try the famous Fred Brooks, Jr. quote (seldom to much success):

'Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into a subroutine--open or closed. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.'

I say something like...

[voxel]

For the generic question, "What is programming?"...

I say along the lines: "Think of programming like any job, where you have employees and you need them to do things for you to make your business work. You usually give your employees a list of instructions, things to do. They do what you tell them to and then come back to you for more instructions. Computer programming is similar, inside that box under your desk are a bunch of employees. Without a boss, they don't know what to do. So, what I do, is I tell each component inside there what to do. I tell the video card to turn on so you see stuff on your monitor as one example. I tell the main processing unit (think of it as the manager of the office, where as I am the big-cheese boss)) to run the "office" while I am away. I give the main manager, or CPU a big huge list of instructions that say this is how we run the place. The CPU (or manager) then follows my instruction sheet and tells all the other components inside the computer how to act, behave and what to do. We do it this way because it take months to write the instruction sheet out for the CPU, but the CPU can execute that instruction list super fast, much faster than if I were telling each component (e.g. employee) what to do directly...".

I actually just came up with this example right now on the fly... I never use the same example, I always think about what that person does for a living, spare time, hobbey, and I can almost always draw parallels that make them say "Ahhh, I wish someone else would of explained it that way before".

I've even explained how interrupt handlers work in regards to a USB joystick to a Lawyer... He was so happy in the way I explained it to him, he kept asking more and more questions until I told him I have to go :P

Easy.

[Anonymous Coward]

The difficulty arises when a programmer tries to teach someone that isn't even computer savvy programming in two minutes or less. It'll never work! Instead of trying to teach programming, simply explain the level of difficulty.

They usually have an intimate understanding of their field of expertise. Pick a complex process from that field and ask them to detail it mathematically. Or better yet, ask them to detail it using nothing but ones and zeros.

They'll think it's a joke at first but, assuring them that you're serious and that it is that complex, they'll start to understand. They'll also probably not need the lesson in programming to understand that it's complex.

Otherwise, you could just piss them off by using the standard line; 'It's technical. Someone like you really wouldn't understand.' Then stand back and watch their blood boil.

Re:I don't (anymore)

[Sigma 7]

Heck, we can't even clearly explain to peer programmers why vi is better than emacs, XP is better than Linux, Gimp is better than Photoshop

This is mainly because the best programs are Notepad, MacOS X, and Corel Draw.

On a serious note, you can't explain these examples clearly to peer programmers because software is not a black and white world. While Windows 95 makes hardware access much easier because of the driver-based architecture, you can guess what happens when you install it on your 386.

I shrug my shoulders and explain it's mostly dull. It's kind of like doing Math homework, except I have to do it every day for my job.

A slightly better explaination is that it's more like building a car, "hot-rod" style. In this case, it sounds much more impressive than it really is - as well shows the correctness of the situation.

Programming is developing individual software components (e.g. an engine, muffler, etc.), and assembling them into a large application (e.g. the car itself.) It's straight forward and accurrate - some software components are stock, some are custom-built for a specific application. The result is that applications generally do the same thing, but have slightly different internal workings, in the same way that cars do.

It's a straight forward explaination as long as you stick to the cliched analogy of cars.