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

Comments

Re:I don't (anymore)

[Rosco P. Coltrane]

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

Well, you can't because they're not the same thing: vi is a text editor, emacs is an operating system.

Software as a machine

[Profane MuthaFucka]

Make a rough analogy. Every line of code is a part of a machine. It interconnects to other parts.

-A mouse trap has maybe 4 or 5 parts.
-A transistor radio has perhaps 100 parts.
-A 35 MM camera has maybe 200 parts.
-What does a car have? 10,000 - 50,000 parts?
-An airplane? 200,000 parts?

-A smallish computer program has between 10,000 and 50,000 lines of code.
-Something like an OS kernel might be between a million and 50,000,000 lines of code
-A typical commercial billing application might have 300,000 lines of code.
-A nice set of apps to run telephony switches might have 10,000,000 lines of code.
-Even your stupidest sort of hackish utility has 100 lines of shell script.

Programs are gigantic machines - you just can't see them or weigh them.