Slashdot Mirror
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.'
The mind boggles... you make a sensible and sincere compliment, in which is also hidden a secret double-meaning, and at the same time you make claims of having a girlfriend. I'm impressed at your literary prowess! ;-)
the layman's guide to computer science
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.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
pictures help, metaphores help, madlibs help
by madlibs, i mean things like "think of [concept] as like a [cute noun (bunnies, kittens, etc.)]"... draw funny pictures, and connect them up with arrows... you can't over simplify enough, and the more fun you make it, the easier time the audience will have following you
remember that 9 times out of 10 you aren't explaining it to these people because they need to understand, you're explaining it so they have confidence that you know what you're doing and that the outcome will reflect well on themselves
When it comes to people who aren't in the code, my explanations fall flat.
Before I changed line of work (I'm not a computer professional anymore thank goodness), I used to explain my work like this:
See, what I do is programming. Programming is like writing a cooking recipe, only slightly more complex but not much more. But it's a very large recipe, and it relies upon many more recipes to make an actual dish (the program). Many cooks write recipes in different languages separately, and all we cooks have to coordinate to prepare the final dish. So we need chief cooks (managers) that call meetings and prepare Gantt charts to do that. Then sometimes a cook writes a recipe that has the wrong combination of ingredients, or that make no sense to describe how to prepare food (bugs), so we need tasters (QA) to tell us busy cooks if the overall result will be pleasing to the restaurant's customers. In the end, you get a huge dish that has some nasty morsels in it, as well as tasty ones. We then have to refine the dish so the nastyness goes away and more goodness goes in (new versions). etc etc...
The cooking recipe analogy has always worked great to explain what I did.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Easiest way I've found- though it's begining to get a bit outdated thanks to bloatware. Charles Dicken's famous novel is about 100k.
You're way behind my friend: data bloat has grown so much these days it isn't measured in Charles Dickens units anymore, it's measured in tax code units:
- 1 tax code = 25MB
- 1 tax code table of content = 300KB (to measure smaller data units)
And no, I'm not kidding, the complete internal revenue code really is that big.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
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.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!