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.'
Spanning 20+ years in computer programming I've stopped trying to explain what it is like and how it is done. 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 (NOTE: these do not necessarily reflect my opinion, FTR, I prefer: vim; Linux; and Photoshop)
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. It's always about solving and debugging, and people's eyes glaze when I begin poking programming nuance with a ten-foot pole.
Fortunately I find most people don't really care. (Also for those who would "get it", my experience has been they are ones who dabble and experiment in it anyway already.)
(Aside: as for the original poster, congratulations on being able to explain "big O notation". I sometimes suspect my girlfriend of faking it.)
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. This makes it easy to estimate source code in terms of number of copies of that novel. The quarter-million lines of code project I'm currently working on takes about 25 MB to store- 25000k, or 250 copies of A Christmas Carol.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
As with explaining the complexity of anything, you have to try thinking either in terms that are completely universal, or in terms that the person you're explaining it to will understand from their field (assuming you know enough about their field to make an analogy, of course).
I usually end up rambling on until the listener's eyes glaze over, but I've had some success with demonstrating some relatively simple things with a deck of cards... sort and random algorithms are especially well suited to this type of explanation, for obvious reasons.
Anything that doesn't have an easy analogy in common knowledge, I don't generally worry about explaining beyond some noncommital answer involving a basic description of the task, then asking the listener to think about breaking it down into simple parts, with directions that a six-year old could follow. Generally works, and gives an idea for the complexity of a program, at least sufficient to give somebody who doesn't really need to know everything about the programming side an idea of the work involved.
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
If you're looking for the perfect 4-course meal at a fancy restaurant, you need to match flavors, textures, and colors from a lengthy menu, weigh the transitions from appetizer to main course(s) to desert, and fit in the perfect glass of wine and the ideally sized, shaped, and sweetened dessert.
Only it's a 100-course meal, the menu is 1000 items long, there's a cellar full of wines (most of them are unpronounceable) and it takes months to find a sequence that people will even TRY to eat all the way through.
And even then, they probably won't be satisfied enough to tip you very well, so you keep making slight tweaks to the courses until someone finally gives you the tip you want. At that point it's good enough, but everyone knows it's never perfect. (And they call you on it, too.)
As soon as someone notices that you're making a decent tip, the owner invariably decides they're going to serve Chinese food instead, so you start over.