Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Explaining Complexity in Software Development?

Cliff posted more than 8 years ago | from the just-don't-have-the-right-words dept.

202

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

cancel ×

202 comments

Sorry! There are no comments related to the filter you selected.

I don't (anymore) (3, Interesting)

yagu (721525) | more than 8 years ago | (#15313732)

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

Re:I don't (anymore) (4, Funny)

Ithika (703697) | more than 8 years ago | (#15313812)

(Aside: as for the original poster, congratulations on being able to explain "big O notation". I sometimes suspect my girlfriend of faking it.)

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! ;-)

Re:I don't (anymore) (1)

SpacePunk (17960) | more than 8 years ago | (#15314063)

I found his post to be almost believable up untill the part about the girlfriend. This Slashdot, after all.

Relationships in the modern era... (1)

hackwrench (573697) | more than 8 years ago | (#15314631)

Given the dying state of society, I find anyone suspect when they claim to have a boyfriend or girlfriend. If people against homosexuality spent as much time helping people get together as they did harping against homosexuality, I wonder if there wouldn't be as much homosexuality because it seems some of it is due to lack of options.

Re:Relationships in the modern era... (1)

SpacePunk (17960) | more than 8 years ago | (#15314703)

Bah, there are always options. You just fail to recognize them for what they are.

Re:Relationships in the modern era... (1)

hackwrench (573697) | more than 8 years ago | (#15314764)

Fine, I'll just tell that to my imaginary friends, as those are the only kind you can meet these days.

Re:Relationships in the modern era... (1)

SpacePunk (17960) | more than 8 years ago | (#15314979)

LOL, ok Exidor.

Re:Relationships in the modern era... (1)

SpacePunk (17960) | more than 8 years ago | (#15315031)

But, seriosly, remember that girl that smiled at you today (yes, it happens every day)... you could have your face between here tits, shakin yer head, making "bbbbbbbbbbb" noises in less than a week if you recognized her smiling at ya. If not, well you need to get out of the basement.

And go where? (0, Offtopic)

hackwrench (573697) | more than 8 years ago | (#15315433)

Sometimes I go out to eat at Taco Bell or Arby's or a Chinese Buffet. Usually they're empty, though sometimes there are people much older than me there, mostly grey hairs, sometimes a mother with her, I'm guessing junior high school daughter, sometimes there are couples. There are stores, a Wal-Mart and Gamestop. What should I do? Saying to get out of the house is one thing, but everyone else is hiding out in their house, because there's nowhere they want to be, nowhere to be.

Re:And go where? (1)

hackwrench (573697) | more than 8 years ago | (#15315497)

As I wrote that, I pondered how the restaurants made money with no one there, and then I realized: Takeout, even the Chinese Buffet. Oh, and I also go to Steak and Shake.

Re:I don't (anymore) (5, Funny)

Rosco P. Coltrane (209368) | more than 8 years ago | (#15313826)

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.

Re:I don't (anymore) (0)

Anonymous Coward | more than 8 years ago | (#15314282)

If emacs is an OS why does RMS care if linux is not called GNU/linux? Is he planning on using the OS kernel from emacs for Hurd?

obligatory... (3, Funny)

jannesha (441851) | more than 8 years ago | (#15314411)

emacs would make a *great* operating system, if only it came with a decent text editor.

(I'm sure you've all heard that one before)

Re:I don't (anymore) (1)

DahGhostfacedFiddlah (470393) | more than 8 years ago | (#15314442)

Are any other real geeks worried about that "Informative" rating?

Re:I don't (anymore) (1)

poot_rootbeer (188613) | more than 8 years ago | (#15315209)

vi is a text editor, emacs is an operating system.

Can't be. Last I hurd, RMS has never released an operating system.

Re:I don't (anymore) (1)

notyou2 (202944) | more than 8 years ago | (#15313832)

Says yagu:
(Aside: as for the original poster, congratulations on being able to explain "big O notation". I sometimes suspect my girlfriend of faking it.)

I'm sure I could take that sentence out of context and make a joke about it. Lucky for you, I'd never do such a thing.

Re:I don't (anymore) (2, Informative)

Sigma 7 (266129) | more than 8 years ago | (#15314814)

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.

My favorite: A Christmas Carol (3, Interesting)

Marxist Hacker 42 (638312) | more than 8 years ago | (#15313802)

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.

Re:My favorite: A Christmas Carol (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15313911)

LOC != complexity.

Re:My favorite: A Christmas Carol (1)

Marxist Hacker 42 (638312) | more than 8 years ago | (#15313948)

True- but novels= complexity in people's minds, and they're always measured in numbers of words. Note- I only put forth my quarter-million lines of code project as an example- the real comparison is space taken up by the source code of both the novel and the project. 25 MB is 250x 100kbytes....

Re:My favorite: A Christmas Carol (1)

frosty_tsm (933163) | more than 8 years ago | (#15313992)

Actually... it's pretty close, but not for the same reason.

Roughly speaking, adding more lines of code (or compressing what should be multiple lines into one) adds more complexity to the application (when you look at debugging, maintaining, and improving it). It is not a measure of value, but can demonstrate how complex an application has become.

Re:My favorite: A Christmas Carol (1)

Anonymous Crowhead (577505) | more than 8 years ago | (#15314052)

I disagree. What's more complex? A 100 line verbose function or one that does the same thing using recursion but is only 10 lines. A trash novel or a haiku?

Re:My favorite: A Christmas Carol (0)

Anonymous Coward | more than 8 years ago | (#15314334)

In general, more lines(useful, functional lines) = more complex, simply because there will be more than what we can hold in our conscious memory at one time. Extremely slimmed-down, tweaked, and optimized code can become nasty, too, but it will usually take more developer time to make the code that small than to do it in a naive, straightforward way, get it "good enough to use," and then move on.

One of the reasons higher-level languages are always touted as being better for rapid, maintainable development is because they can use fewer LOC in almost every area, from the heading boilerplate to the number of expressions used in each algorithm.

So yes, I would say that LOC are a good way to go about explaining it to the layman. The per-line complexity is merely a technicality if you're talking about any sort of sizable project, because it will almost always average out to some medium-low level of complexity, even if some bits are very clever. (though as the project gets bigger the average complexity is likely to creep upwards as features start conflicting with each other)

Re:My favorite: A Christmas Carol (1)

ceoyoyo (59147) | more than 8 years ago | (#15314917)

The 100 line function and the trash novel are more complex. The 10 line function and the Haiku are simpler. Also, more elegant and better.

Program Complexity != Word Count (1)

Rob_Warwick (789939) | more than 8 years ago | (#15314102)

At University, during the end of the semester when my friends were all writing essays like mad, or in my case writing code, I ran into the disconnect that exists between programming and some other disciplines.

First off, friends would say that they had four essays, with exact word lengths for all of them. In the course of talking about what we all had to do I got asked how many pages my final project was supposed to be. Naturally I said that I didn't have a set page length, as long as it worked and was written efficiently and with good form.

Programming can't be correlated to word counts. Talented programmers can do stuff with less code. Bad programmers can do stuff with much, much more code. Clever programmers can do the same stuff with tiny amounts of code, but $DEITY help the poor guy who has to maintain it.

If you're just trying to get across a general idea of how complex code is, I'm somewhat fond of the 'full course meal' analogy. It's like cooking anything from a snack to a twelve course meal for a large number of people. Even though each dish is independent (if you do it right, I'd hate to see a dinner without good division between the dishes), each of them affects the meal as a whole as well.

Re:Program Complexity != Word Count (1)

hackwrench (573697) | more than 8 years ago | (#15314645)

Yeah, and you can submit the same essay to more than one class!

Re:My favorite: A Christmas Carol (1)

elronxenu (117773) | more than 8 years ago | (#15313936)

Not only that, but 250 copies of A Christmas Carol where if you get a word wrong, the whole novel may crash and burn.

Re:My favorite: A Christmas Carol (1)

ceoyoyo (59147) | more than 8 years ago | (#15313973)

Not only that, but misspellings and grammar mistakes are the least of your worries. More important is that everybody reading it interprets the meaning of the sentence/chapter/paragraph in exactly the same way you do.

If that were the case imagine how many English degrees there wouldn't be.

Re:My favorite: A Christmas Carol (2, Insightful)

Clueless Moron (548336) | more than 8 years ago | (#15313945)

Well, you could do that. You could also compare it to the Bible, which is about 4M.

Or you could compare it to a DVD of "Dumb and Dumber", which at 4.7G is 188 times bigger than your 25M quarter-million line code project.

In short, bulk? Don't go there.

Re:My favorite: A Christmas Carol (4, Funny)

Rosco P. Coltrane (209368) | more than 8 years ago | (#15313984)

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.

Re:My favorite: A Christmas Carol (1)

Marxist Hacker 42 (638312) | more than 8 years ago | (#15314078)

I think I'll use that at our next team meeting when the project manager asks why something breaks every time we fix something else.

Re:My favorite: A Christmas Carol (1)

heinousjay (683506) | more than 8 years ago | (#15314799)

Just say the magic words: 'tight coupling'

Thoughts (1)

Xugumad (39311) | more than 8 years ago | (#15313810)

Tell them to imagine something constructed from LOC pieces of Lego.

More usefully, try explaining why code is complex. Focus on the idea that you have an insane number of moving parts (effectively), but modifying is nearly free, which is why it works at all. Also mention things like spending most of your time writing error handling (well, I do, anyway :) )...

Re:Thoughts (0)

Anonymous Coward | more than 8 years ago | (#15315975)

"More usefully, try explaining why code is complex. Focus on the idea that you have an insane number of moving parts (effectively), but modifying is nearly free, which is why it works at all"

Well, that's O-notation, in a sense.

There's the old (french) anecdote about the pharao asking Euclides about teaching him maths. Then he pointed out to his geom book. The pharao said it seemed too difficult, so he asked for a shortcut. Sir, there's no shortcuts even for kings.

Software is difficult because it's made up from "bricks" which can interact almost freely with each other; that makes the top number of interactions up to 2^n, where only one being "correct". The task of the programmer is not only to build the bricks, but to find the one way out of 2^n to mount all the pieces.

If someone is not even able to understand this, he shouldn't be out of a charity for mentally unfitted.

madlibs! (4, Insightful)

conJunk (779958) | more than 8 years ago | (#15313829)

:) i used to teach english to native japanese speakers, and that's really not any different from trying to explain bayseian spam filters to my non-technical boss.

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

Re:madlibs! (3, Funny)

Rosco P. Coltrane (209368) | more than 8 years ago | (#15313935)

i used to teach english to native japanese speakers, and that's really not any different from trying to explain bayseian spam filters to my non-technical boss.

Here's a challenge: try to explain bayesian filters to a non-technical native japanese speaking boss.

Well, you wanted a MADlib... (0)

Anonymous Coward | more than 8 years ago | (#15314862)

> Here's a challenge: try to explain bayesian filters to a non-technical native japanese speaking boss.

I think you'd say something like, filling in the blanks as required:

"Battousai-chan no jutsu ____ na shime wa kokorono. Hikariga to ____ fuiteru Kwabaru-baka na Kagome-sama de arimasu."

Don't worry if their eyes glaze over and they look *REALLY* confused. That's perfectly normal... :-)

Re:Well, you wanted a MADlib... (0)

Anonymous Coward | more than 8 years ago | (#15314940)

Deijii wa masu-masu tsuyoku-deru youni natte-imashita.

Brooks explained it: It's the programmers' fault! (1)

Swave An deBwoner (907414) | more than 8 years ago | (#15313843)

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

See, that's the problem, and it's the programmers that caused it. Stop making subroutines. Monolithic code be da shizzle on da bizzle.

I say something like... (2, Informative)

voxel (70407) | more than 8 years ago | (#15313848)

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

Re:I say something like... (1)

elronxenu (117773) | more than 8 years ago | (#15313968)

I've even explained how interrupt handlers work in regards to a USB joystick to a Lawyer...

I can just imagine you telling it in terms of Plaintiff and Defendant and an "Emergency Request for Permission to file an overlength memorandum in support of SCO's new Renewed Motion to compel discovery" to which the Judge must respond immediately.

Re:I say something like... (1)

avalys (221114) | more than 8 years ago | (#15314107)

Good for you. That's an explanation of how computers work. It's not an explanation of how complex software systems are.

Oh boy (2, Funny)

woolio (927141) | more than 8 years ago | (#15315590)

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

Ah great.... Now your lawyer is going to wager a class-action lawsuit on behalf of all USB devices for illegal discrimination and unfair employment practices by the interrupt controller. The PCI bus will be named as a conspirator and the CPU will be charged with negligence. The PCI sound card will be the chief witness.

Stupid quote (2, Insightful)

2nd Post! (213333) | more than 8 years ago | (#15313861)

The quote you use is pretty bad, especially for people that don't know software:

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


What you want to convey, to the non software initiated, is why software is difficult, why it is complex, and why it is hard.

I would put it this way; software is really "soft", being only instructions a computer reads and interprets. A physical analogy is perhaps clay, something equally analogously soft, malleable, and easy to work with. Now imagine another physical analogy; take that clay, and then try to build a car out of it. A working car. Ignore the physical impossibilities, like combusion temperatures, but make the point that each component first has to be designed then baked, and that each component has to be integrated with each other component.

So that is what software is like. They may ask, "Why?", and here are a few reasons:
1) Software is easily copied, not easily designed. The hard part is making the first copy, as in the car example. Once you get one product finished, you can copy quite easily, but actually designing and building is not necessarily easy.
2) Software is REALLY malleable. You can continuously change the design as you are working, not unlike building an entire car out of soft clay.
3) Because software is so malleable, each time you discover a new problem you discover a new solution. In other words, the second car you make will be totally different than the first car because instead you will be going from a car to a boat or a train or a helicopter.
4) Also because software is malleable, every "customer" with different requirements brings in new design directions. Imagine if every person working on the car, viewing the car, and interacting the car wants a totally different car? You aren't designing one car, now, you are designing 17 or 18 cars; trucks, vans, compacts, sedans, and sports cars. Now take all these vehicles and merge them into a single multipurpose vehicle.

Re:Stupid quote (1)

Beryllium Sphere(tm) (193358) | more than 8 years ago | (#15313952)

>each component first has to be designed then baked, and that each component has to be integrated with each other component

"Windows XP has 65 million lines of programming instructions. They all have to work together. Imagine a jigsaw puzzle with 65 million pieces. Better, imagine that the puzzle is three dimensional."

"Windows XP has 65 million lines of programming instructions which have to work together for a common goal. Imagine managing a bureaucracy with 65 million employees and getting it to work reliably."

Re:Stupid quote (0)

Anonymous Coward | more than 8 years ago | (#15314266)

What's that? XP Works now? How come that isn't on the front page? :)

Re:Stupid quote (3, Funny)

iomanip (775663) | more than 8 years ago | (#15314392)

Please, whatever you do, no more software-car analogies!!!!

use acronyms (1)

saturnism (177882) | more than 8 years ago | (#15313871)

say a sentence constructed full of acrynoms that describes are you build your system

Depends on the audience (3, Interesting)

nosredna (672587) | more than 8 years ago | (#15313875)

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.

I like legal analogies (2, Funny)

sedyn (880034) | more than 8 years ago | (#15313887)

Imagine having a huge legal contract. Then, add in a huge, convoluted yet intertwined legal system.

Furthermore, imagine that instead of writing this legal mumbo-jumbo in english, you use a language that is extremely strict and math-based.

This would be a fraction of the real complexity (mutiple threads/processes anyone? How about poor documentation?) but it starts the ground work.

To be honest, this way of thinking sounded better when I first started, and I'm kind of disapointed with my end product.

Re:I like legal analogies (1)

ceoyoyo (59147) | more than 8 years ago | (#15313988)

It's too bad lawyers DON'T write things in a strict language. With syntax checkers.

Re:I like legal analogies (2, Interesting)

mOdQuArK! (87332) | more than 8 years ago | (#15314370)

I thought it would be interesting if it were required that all legal documents be written in an unambiguous computer-parseable language.

Decision points where ambiguity had to be resolved would be referred to human actors (judges, government officials, etc) who would have to provide their decisions in terms of data that was unambiguously interpreted (in terms of the legal language).

Couple of benefits that I can think of (aside from reducing the number of arguments about what the laws actually mean):

1) Trials could be reduced to a "legal" computer, where the prosecutors & defense lawyers write their cases in terms of the legal language, feed it into the computer, the computer asks the judge & juries to make decisions at key points, then renders the verdict.

The more interesting possibility was being able to "test" the effects of new laws by running through large population "simulators", and try to forecast how they might affect your society.

I discussed my brilliant idea with my brother (a lawyer), who laughed at me and told me to get a life. *sigh*

Re:I like legal analogies (1)

ceoyoyo (59147) | more than 8 years ago | (#15314467)

What your brother (a lawyer) really meant was "please don't tell anybody who might think that's a good idea because then my expensive degree will be worthless."

He's safe though -- most politicians are lawyers too.

I think it's funny that the system that holds our society together and governs its interactions requires interpretation, judgments and a large group of people to discuss and explain it all to the rest of it. Hm... kind of sounds like religion actually.

Re:I like legal analogies (2, Insightful)

eddeye (85134) | more than 8 years ago | (#15315864)

What your brother (a lawyer) really meant was "please don't tell anybody who might think that's a good idea because then my expensive degree will be worthless."

Actually what he meant was "Law can't be pinned down to precise language out of necessity. Specifying exact rules to cover every particular case is an impossible task. You can't foresee every possibility and even if you could there are too many factors to account for. It's an infinitely larger search space than chess, which is itself completely unmanageable. Hence law mostly relies on relatively short rules and human intelligence to apply them correctly in each situation." Where 'short' means someone who knows where to look can process the relevant ones in finite time.

I'm a programmer and a law student. Trust me, precise grammars are not an option.

Re:I like legal analogies (1)

ceoyoyo (59147) | more than 8 years ago | (#15315935)

I think there are different types of law. A VERY precise language should be required for contracts, for instance. In other areas, the Latin and ye olde English provide an artificially high bar for laymen, and should be eliminated in favour of a more human readable format.

My analogy (4, Interesting)

Rosco P. Coltrane (209368) | more than 8 years ago | (#15313916)

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.

I like the cooking analogy, but also stress DESIGN (3, Insightful)

arete (170676) | more than 8 years ago | (#15314142)

I like your cooking analogy, but there's one thing missing:

One thing I can't stress enough to people is that programming is all DESIGN/ARCHITECTURE. The "do" part is essentially instantaneous. You figure out how to do something and write it down, in every minute detail (in code) and it's basically done. Then you compile it (or not even for some things). This process is nearly instantaneous (perhaps minutes but never days for almost any project, and never something you need to do yourself...)

To expand your cooking analogy, it would be like you work really hard on these recipies, but whenever you want you can "zap" create a new set of dishes. (Except that then you have to taste them all again to make sure your changes are ok..)

This is fundamentally different from the construction of anything else ever in my opinion. Code is akin to a recipe or blueprint. The "compile" part of programming, which takes zero work on the part of the programmer, replaces what is one of the longest and most costly parts of developing anything else.

Furthermore, it replaces the only part that you can reliably predict the duration of - making it very, very difficult to predict how long it will take to develop a piece of software.

I think it's important to realize that this makes software much faster to develop - if less predictable - but therefore we develop much more complex things in software. So to borrow from another analogy I saw here - because we don't have to physically build them, the expectation when building a car is that it'll have every feature of any car, boat, bicycle or plane that ever existed.

(The other important ramification is that it never saves developer time to remove an existing feature - and in an agile development process it may take more time to DECIDE whether a feature is important than it would have to simply implement it.

Re:I like the cooking analogy, but also stress DES (1)

Eneff (96967) | more than 8 years ago | (#15314251)

In other words, the better the kitchen, the more reliable the dishes will be, and the faster the cooks will be.

Re:I like the cooking analogy, but also stress DES (0)

Anonymous Coward | more than 8 years ago | (#15314867)

Well, there's zapping and there's zapping. Our full clean build takes the best part of 18 hours on the fastest dedicated hardware we can get.

Re:My analogy (3, Insightful)

Mignon (34109) | more than 8 years ago | (#15314477)

I know exactly what you mean. My customers come to me and say, "I'm hungry and I want a healthy meal! I like ice cream, cookies and liverwurst. To eat it, I've brought my favorite chopsticks and a slotted spoon. Oh, and can I get that to go?" And after I make it, they point out how they're allergic to milk products.

Re:My analogy (1)

BMazurek (137285) | more than 8 years ago | (#15315055)

Thanks. This is the first response I've seen that is at least along the lines of the response I was hoping to get. My problem with these sorts of explanations, is it still doesn't capture the complexity.

When you're writing code that you've never seen anyone do before. Doing things across multiple languages, building infrastructure. But because you've never seen anything like this, and certainly never looked at the code for anything similar, how do you explain why your time estimates can be so off?

Alternatively, why does the industry have so much difficulty with deadlines? What makes development complexity defy good planning? Are we really an entire industry of bad planners? Not all software projects take longer than expected to develop, but those are either relatively simple or relatively straightforward. When software becomes complex and / or more researchy, it appears the complexity overtakes our ability to propertly estimate.

Why?

The best example I had (especially for the more R&D-y projects) was this: you're given a vague drawing of a scene. It's a relatively tight photograph. You think the scene is in L.A. (or some other sufficiently large city). Go find the photograph. All you have is a vague out-of-focus sense of what it is you're looking for.

Now some people might complain that what I'm describing is a poorly designed system or poorly described requirements. That may be partially true, and that may be the case for the more straight-forward projects. But when you're doing something relatively unique, all you have is a known destination (an in-focus picture), not the actual location (where the photo was taken).

Re:My analogy (1)

pete-classic (75983) | more than 8 years ago | (#15315080)

You forgot the part where if you put the paprika in one step too soon it will kill everyone who eats it and put you out of business.

Oh, and that it is often not obvious just when is too soon, so you have to find out experimentally.

Why yes, yes I do work in QA.

-Peter

it's like serving food at a restaurant (3, Interesting)

silvermorph (943906) | more than 8 years ago | (#15313921)

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.

Re:it's like serving food at a restaurant (1)

eddeye (85134) | more than 8 years ago | (#15315834)

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.

Nice try, we know who you really are [slashdot.org] .

Teach them to program. (1)

DrJimbo (594231) | more than 8 years ago | (#15313966)

As you have discovered, it is not possible to teach people about abstract concepts in terms of other abstract concepts they don't already understand.

You time will be better spent teaching them the basics of programming that will give them something concrete upon which to build abstractions.

I suggest using an elementary teaching aid such as the Cardiac Cardboard Computer [bellsystemmemorial.com] . You can still buy them or you can download pdf's and make your own. I don't know about the legality of the downloads.

Software as a machine (5, Insightful)

Profane MuthaFucka (574406) | more than 8 years ago | (#15313998)

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.

Re:Software as a machine (1)

Snowhare (263311) | more than 8 years ago | (#15314170)

Bingo.

The last sentence is the whole thing in the most concise form I have ever seen it stated.

Re:Software as a machine (1)

Surt (22457) | more than 8 years ago | (#15315085)

The boeing 747 is composed of roughly 6 million parts.
http://www.boeing.com/news/feature/747evolution/74 7facts.html [boeing.com]

I can't find a cite, but I'd guess you are off by an order of magnitude on the car as well.

in total or unique? (0)

Anonymous Coward | more than 8 years ago | (#15315773)

6 million parts in total or 6 million unique parts?

Spaghetti (1)

Zork the Almighty (599344) | more than 8 years ago | (#15314036)

I tell them it's like chopping up your bowl of spaghetti and trying to build a model ship.

Easy. (1, Informative)

Anonymous Coward | more than 8 years ago | (#15314049)

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.

feh (1)

bunions (970377) | more than 8 years ago | (#15314072)

"Software entities are more complex for their size than perhaps any other human construct because no two parts are alike"

I don't believe this. I think developers think that's true because they haven't been exposed to other large constructs.

I tend to think it's complex because we haven't figured out a really good way to do software engineering yet. Just like every car was handmade and fragile when horseless carriages were first concieved of, software today is handmade and fragile. Someone, somewhere will eventually figure out how to grow it or make it on assembly line or whatever.

Re:feh (1)

epee1221 (873140) | more than 8 years ago | (#15314900)

Someone, somewhere will eventually figure out how to grow it or make it on assembly line or whatever.
A car is a replicable solution to a common problem. Thus cars can be mass-produced (manufactured).
A specific piece of software may be a replicable solution to a common problem (MS Word fills the common need for a word processor) or a specific solution to a relatively unique problem (some billing application fills a company's need to automate its own billing procedures). Software of the first type already is mass-produced (copied onto millions of disks). Software of the second type is not mass-produceable like cars are because each piece of software is made to solve a problem so specific that it is not likely to appear again.

Re:feh (1)

bunions (970377) | more than 8 years ago | (#15315505)

"Software of the first type already is mass-produced (copied onto millions of disks)"

The idea that you're 'mass producing' software because you press a lot of CDs is preposterous. By 'mass production' I mean some production methodology like an assembly line or similar industrial process.

"Software of the second type is not mass-produceable like cars are because each piece of software is made to solve a problem so specific that it is not likely to appear again."

No, but eventually someone will figure out how to do software engineering that produces software components people will put together in the same way people put together hardware today.

Pretty easy (1)

c0d3h4x0r (604141) | more than 8 years ago | (#15314081)

Think about how complicated a car is.

Think about how difficult it must be to design something that complex.

Computer programming is thousands of times more complicated than that.

design and mapping (3, Insightful)

Darth_Burrito (227272) | more than 8 years ago | (#15314131)

Software development is hard because at its core it's as much about design and invention as it is about implementation. Implementation, in the general sense of the word, is often fairly easy. You have a plan, possibly a well known and understood plan, you can track progress, things are more predictable. With design and invention, you are often in unexplored territory so it's hard to tell where your next steps should take you and it's hard to track the progress you've made to date. What makes software development even harder, is often that the customers don't actually know what they want nor can they really be expected to know what they want. Problems are often not well understood.

One analogy that I've always liked is to look at software development as a mapping problem. When you start, you're pretty much dropped in the middle of nowhere without much understanding of the surrounding terrain. You then have to go exploring the area around, get an understanding of the feature space. Maybe the best approach is to climb a mountain or a hill, implement or design a major well understood component, and see what you can see about the area around you from that peak. You make little scribbles and notes on your makeshift map outlining what you've seen from the top of your mountain. Later, you climb a different mountain and all of a suddent everything looks completely different from the new perspective and you realize large parts of your old scribbled map are wrong. Maybe walking in between mountains one day you discover a large impassable ravine that was masked from above by foliage. Your in unexplored territory and there can be lots of surprises and setbacks.

Only, I think this kind of mapping analogy really falls short because it only takes into account a single perspective, that of the developer, and it assumes there is some well defined terrain that just needs to be discovered. In reality, the terrain being explored is much more mercurial. Much of it is visible only through the inconsistant and confused descriptions of customers or other developers. It's quite possible that the mountain you climbed yesterday, and the things you saw from the top, will not exist tomorrow.

Anyways, that's the best I've got at the moment. It probably doesn't make much sense, but then, what does?

moving parts (1)

museumpeace (735109) | more than 8 years ago | (#15314144)

A lot more people know something about cars than about software. There is an old rule of thumb that a line of code adds about as much complexity [design complexity, implementation complexity, maintenance complexity] as adding one moving part to a mechanical system...and cars are the one mechanical system most people have experience. [just pray they don't ask about the computer chip in todays cars...which in general, has saved detroit from a horrendous complexity of mechanical feedback systems that would otherwise accomplish pollution control] Cars also have subsystems, eg electrical, transmission is a complex gizmo in its own right etc. so composition of systems from subsystems...one of the essential aspects of modern software, has a good analogy in the automobile. And besides...nobody likes to sound stupid: they might be ok with saying your explaination of software is confusing but they won't admit the car analogy is over their heads...just talk, they'll nod and shut up and leave you alone pretty soon so you can go back to coding.

why it's not like building a house (2, Insightful)

davez0r (717539) | more than 8 years ago | (#15314163)

if someone building a house does something the same way more than once, it's a good idea. they use what they know works, and apply it over and over again. maybe some variations on a theme, maybe add another story here or a differently angled roof there.

but software is different. if you're doing something the same way more than once, it's generally a warning sign that you could be doing it better somehow. following that to its logical conclusion, a good programmer will never do the exact same thing twice. meaning that, as a good programmer, you're always doing something you've never done before.

that is why programming is hard.

it's like being an automobile manufacturing plant that never produces the same car twice. one day it's a civic hybrid, the next day it's an M1A1 tank, and the day after that you need two vespas, one that runs on gas and one that runs on fryer oil.

Complexity (1, Funny)

Anonymous Coward | more than 8 years ago | (#15314229)

I tell people to imaging drawing a simple window on the screen
with text. Now your job is to make any one line of text
slide right when you hold down any one key. simple, right?

Ok, here's a sheet of paper that has text on it.
And here is a Royal mechanical typewriter.
Modify the typewriter to slide the text right when i hold down
the L key.

Oh, and I need it working by tomorrow.

Why is software complex? (2, Interesting)

maxume (22995) | more than 8 years ago | (#15314291)

Because it interfaces the most complex product of evolution(people) with the most complex creations of those people(computers and software). Computers are utterly rigid in what they do, and humans are nearly infinitely variable. Dealing with the differences, with a comparitivly small amount of experience, is hard.

Some software is pretty simple, because it solves simple problems. Is it any wonder that it often takes a complicated system to solve a complex problem?

For the visual folks... (2, Insightful)

kschendel (644489) | more than 8 years ago | (#15314319)

I've had some success illustrating the challenges of programming to the more visual or artistic types with this [ebaumsworld.com] . Then you tell them to multiply that by tens of thousands, at least.

Software is Communication -- that's why it's hard. (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15314352)

Ask them if they've ever seen a foreign movie with really bad subtitles. Ask them why something that seems so easy is so badly done. Ask them if they've ever had to explain something to a child who's only response is "Why?".

Everything that goes wrong with software is a result of miscommunication. From failed projects, to difficult algorithms, to null pointers. Programming is taking difficult to communicate ideas and concepts of human creation and translating them into the most literal and OCD afflicted of entities -- a computer.

You can talk about system size, deadlines, complexity, etc., but it all really boils down to communication. UML, JavaDoc, unit tests, forms, screens, blah blah blah. "Exactly what I asked for and not what I wanted."

Communication is difficult enough between two intelligent adults sharing the same goals. Now imagine trying to explain something to a machine.

Think of this (1)

GWBasic (900357) | more than 8 years ago | (#15314438)

Think of every if statement and loop as a moving part. Using the analogy, a computer program is like a machine with thousands of moving parts.

Think Geek T-Shirt... (1)

creimer (824291) | more than 8 years ago | (#15314441)

How do -you- explain software development complexity to non-developers? What analogies do you use?

There's a T-shirt [thinkgeek.com] that sums it up nicely: I See Dumb People

Easy. (2, Interesting)

Kaenneth (82978) | more than 8 years ago | (#15314461)

"The main processing unit in a computer has Millions of transistors, which are like little switches, turning on and off. These switches flip automatically Billions of times a second. Every second Quadrillions of switches flip, and if a single one goes wrong the computer 'crashes'. That's not even counting the Memory, or the Graphics card, or all the extra devices from Hard Drives to Tempurature sensors that are hooked in. All of these switches are controlled by programs that were written by the combined efforts of thousands of people, most of whom have never met each other. I'm continually amazed every second that a modern computer keeps running."

Why are you doing this? (0)

twitter (104583) | more than 8 years ago | (#15314515)

I can't tell you how to explain software complexity until you tell me why you are doing this, who your are trying to convince and what aspect of "complexity" you want to relate. My general answer is that software is no more complex than any other practical task. My specific answer varies by audience. Talking to people who have never done a practical thing in their lives is different from talking to tradesmen or engineers. Most importantly, what you are really trying to achieve makes a difference. Why are you doing this?

I can think of a few legitimate reasons and many less honest goals. The world is awash with non-free propaganda, which is designed to make the user feel helpless. "Here there be dragons, trust us and stay out," they tell us at every turn right before blowing their horn about how many million lines of code they have bought and hacked together. Raise my spirits with a story of educational and respectful conversation. I'd love to hear about it.

Re:Why are you doing this? (0)

Anonymous Coward | more than 8 years ago | (#15314801)

Who modded this up??

Talking to people who have never done a practical thing in their lives

What? And who the heck would that be? What do you mean? How can you write something so meaningless? To pad your post?

My general answer is that software is no more complex than any other practical task.

You have it wrong, this is about software development, an activity that is obviously completely alien to you. It's not about telling people where the "exit" button is in KDE, it's about writing the exit button (or whatever).

The world is awash with non-free propaganda

What? What the hell does that have to do with anything? Are you back to the old "evangelizing" thing? Please don't start comparing the Gestapo [slashdot.org] or the Chinese secret police [slashdot.org] with Microsoft here, OK?

Re:Why are you doing this? (1)

BMazurek (137285) | more than 8 years ago | (#15315096)

  • I can think of a few legitimate reasons and many less honest goals. The world is awash with non-free propaganda, which is designed to make the user feel helpless.


My wife would like to understand. :) Is it legitimate? Certainly. Is it less than honest. I don't think so. She's definitely non-technical, but exceptionally smart. Her reaction is generally "just plan better". I argue that the industry has been struggling with this issue for decades. I don't think we're all morons to have built so much infrastructure and come so far, but we still can't solve the simple parts like accurately identifying how long it will take us to accomplish our goal.

My wife is just one of several I'd like to talk to about it. They're mostly other non-technical people, although a couple may have engineering or physics backgrounds.

  • Raise my spirits with a story of educational and respectful conversation. I'd love to hear about it.


Hopefully, your spirits have been raised. Now soar...

OK, for the wife. (0)

twitter (104583) | more than 8 years ago | (#15315712)

My wife would like to understand. ... She's definitely non-technical, but exceptionally smart.

That's who and why and I can understand that.

Her reaction is generally "just plan better". I argue that the industry has been struggling with this issue for decades. I don't think we're all morons to have built so much infrastructure and come so far, but we still can't solve the simple parts like accurately identifying how long it will take us to accomplish our goal.

Hmmm, I'm still not sure what you want to explain but I'll take a swing anyway. I can think of social, technical and legal complexities to software development. I've talked to my wife about all three. You might be thinking of something completely different.

Talking to my wife is not all that hard, even though she has no interest in programming. Her first and only practice was some kind of basic in grade school. She was an interior designer for a Steelcase for eight years and understands all three classes of difficulties.

Others have done a great job explaining complexities in terms of free software. Voices from the Open Source Revolution [oreilly.com] has a lot of clear thinking from software masters. Vixie's article about software engineering [oreilly.com] is particularly germain. You can also get a lot of good thought from the Free Software Foundation's [fsf.org] philosophy pages. The Cathedral and the Bazaar [catb.org] deals with the issue explicitly. Indeed, there's an embarrassment of riches matched only by the wealth of text editors in the free software world.

So, how do you get from there to dinner table conversation with the wife who's never written a line of code? It's the same way you try to simplify everything and the largeness of the subject actually helps.

You start with what a program is and everything flows from there. My wife, like most people, understands modularity. "You eat an elephant one bite at a time," is one of her favorite sayings. She also has a basic idea that a program is something that takes information and does something with it. It does not take too much to explain that programs expect specific organization of their inputs to be able to deal with it and that smaller, simpler programs are easier to work with that big complex ones, and the wife then understands modular programming. It's a division of labor kind of thing that runs right into group development and organizational and social complexity. How do you know what the customer really needs? How do you make decisions about meeting those needs and turn those into a blueprint that you can follow? The free software world has solved those problems by letting the customer make the software themselves, and those customers have been organizing themselves very well. At that point, you zoom back into the perspective of a developer getting their hands on some huge project. If you can imagine that the free software developer knows what they want to accomplish, you are then faced with another embarrassment of riches: so many great tools, each of which can take years to explore. Did I say "free software developer"? Yes I did, because I did not want to wade into the swamp of NDA's, cross licensing, binary blobs and other horror stories of legal complexity. That can come later. By now, your wife's head will have popped but you will have explained software development complexity.

Like most things, none of the parts is particularly difficult, there's just a lot of parts.

It's not horribly complex. (2, Insightful)

SanityInAnarchy (655584) | more than 8 years ago | (#15314760)

Ok, it's complex enough. But, the examples I'm seeing in these comments, while they will impress people, are just a bit extreme.

For instance, the analogies around building a car. No, software is all about design. When building a car, you have to deal with real, physical possibilities and impossibilities. In software, if your design is good, the components are flawless.

Also, abstraction helps. A lot. The example of 25 megs of source vs a 100k Charles Dickins novel isn't relevant unless I actually have to work on all 25 megs -- that, and english can often be much more compact. I often make a point of showing people Bash one-liners as an example of good abstraction -- probably millions of lines of code went into what I just did, but I only needed one line of code to make all that other code work together.

When it comes to explaining program complexity, it really depends what misconception the person has. The most common one is that computers are capable of some form of human-like thought -- the form varying from person to person. However, it's usually easier to convince people that something isn't possible than that something is possible, because people are used to thinking of computers as huge, complex, rigid, and buggy.

Honestly, though, the best way to teach someone why programming is hard is to teach them to program. Second-best way is to teach them philosophy. Third-best is to teach them Calculus.

Re:It's not horribly complex. (1)

2nd Post! (213333) | more than 8 years ago | (#15315032)

The problem with your statement, "If your design is good, the components are flawless," is that design is an activity that defines both the problem and the solution. If your problem is ill stated or unexplored, your solution is equally ill stated and unexplored.

There are several analogies that apply to software: It is complex because it is self similar, so that the lowest level of design is about as complex as the highest levels of design, or it is complex because humans are not naturally gifted at translating between reality (the problem space) and language (the design space and the communication space).

Unless you are simultaneously the customer and the implementor, you will have to struggle to get the right problems first, then the right solutions, and then the right implementations from the right people.

I say.. (1, Interesting)

Anonymous Coward | more than 8 years ago | (#15314781)

Imagine a very complicated machine, like the Boeing 777 airplane, which took years to design and build, and has millions (? actually not sure) of parts.

Imagine that each of those parts can directly affect 2-3 other parts.. the ones that it is connected to physically or electrically, etc. That gives you a huge set of possibilities for parts to fit wrong, or wear out in unexpected ways, or otherwise fail.

That's a pretty complex system, right? In fact, it's almost amazing that human minds can conceive, let alone build and deploy, such a complex system.

Now.. imagine that you've got millions of parts, and each part can potentially interact with EVERY OTHER PART. Also, imagine, because it's such a young field, there really isn't much common vocabulary or theory, and incompetent practitioners pretty much have the same power as seasoned veterans (perhaps more so in some cases). So things are designed and built in an ad-hoc manner rather than with careful engineering discipline.

That's what programming is like. So don't complain when Windows crashes or you can't get to your favorite web site.

Explain by analogy/example (2, Interesting)

(Score.5, Interestin (865513) | more than 8 years ago | (#15314844)

If I've got 5-10 minutes, I use a simple exercise of getting them to sketch out a program for a humanoid robot to set the table, i.e. to carry cutlery and food from the kitchen to the dining table. Before they begin, they consider it a trivial task. After about 5-10 minutes, they accept that even this "trivial" task is close to impossible. Here's an example: First, you have to get the thing to walk from the kitchen to the table. So you have to teach it to walk. Then you have to teach it to avoid obstacles. I tell them that their robot has just crushed the cat (it's not a chair or table, which was their understanding of an obstacle). So they modify it to avoid small furry objects... and kill the dog, which is large and furry. So they modify it again, and find that it's frozen in front of a throw rug, which is small and furry. So they modify it again, and find that it's been halted by a sleeping cat. Then you throw in exception conditions, e.g. a fire, or even just the phone ringing so the robot has to clear the way for someone to get the phone... it's fairly easy to demonstrate that even the apparently most trivial task is in fact incredibly complex once you have take all the different conditions into account, and depending on how much time you have (and how long they take to convince) you can keep throwing hurdles at them almost indefinitely.

are you sure it's that complex? (0)

Anonymous Coward | more than 8 years ago | (#15314910)

This is kind of contrarian, but I don't agree with the premise that software is really that complicated. I am an embedded software engineer at a medium sized American company. I work in a group with about 30 other programmers, but the company as a whole must have more than 1000 people that write software. It's easy to sit back and think, "Wow, I'm really smart so this stuff must be hard." But certainly most of the people I work with _aren't_ so smart, they're just run of the mill college graduates with engineering degrees. Basically, given a progamming problem, it is solvable by about anyone who knows about programming. Sure, the solutions vary in elegance, code size, defect rates, etc., but it's kind of like every other engineering job. There are a few small engineering tradeoffs, you get more experience as you do it so you make better decisions, and everything else is economics - based on how long something takes to code up, will customers pay enough to generate a profit?

The only thing I can think of that might make it seem like software is complicated is that it is error-prone. But this is by choice, people are just lazy :-) But seriously, if you treat it like a discipline and not an art, the number of mistakes you make as an individual programmer should go down over time to basically nothing. (No, I'm not there yet... I am currently porting code from one embedded platform to another, and I am definitely introducing mistakes :-)).

If I had to list some great software and think about how complex it is...
google maps... cool idea, fantastic implementation, but complex? It's a freakin' map with an API
The linux kernel - fantastic open source, but isn't writing an OS something you do as a sophomore in college? again, not rocket science.
gcc - actually, writing gcc would be pretty hard. But have you seen how badly it optimizes? The hard parts aren't done yet.

The fun part of software for me is the idea and the design... after that it's just implementation, trying not to introduce errors.
And not introducing errors in the idea and the design :-)

When I tell people what I do, I either joke that I play games and watch movies all day, or I tell them I'm a typist if I'm being honest.

Depends on who you are talking to... (1)

zogger (617870) | more than 8 years ago | (#15314947)

...I guess. To my girlfriend, using a cooking recipe analogy would be more appropriate (fast food meal, 18 course high level fatcat state dinner in Paris, etc), whereas talking to any of my bubba gearhead friends, I would use cars (engine/drivetrain/body/accessories, etc).
You would have to tailor (there's another one, garment construction and weaving and different materials and threads, etc) the analogy to what that person already understands in their field of interest/expertise.

Myself, I don't want to know, I'd rather ya'all smart guys who can type fast slug it out, see who wins, I just want my browser secure and printer to print, thankew so much and stuff. And here ya go, have a nice fat strawberry just came out of my garden today, I manage "solar photosynthetic energy conversion" combined sentient and non sentient biological factories with a little "terraforming" on the side. You'll have to figure out what analogy might work for me to 'splain programming...what I have figured out is that part of it requires you to really rag on other dudes over whether to use sanskrit or aramaic or something like that. All greek to me...

Network interactions theory (1)

Tablizer (95088) | more than 8 years ago | (#15315307)

Something simple yet power is the network node connection count. The potential interactions between nodes grows out of proportion to the number of nodes. In software, all factors can potentially affect all other factors, expecially in biz apps. Here is a sample chart:

Node - Interactions

2 - 2
3 - 6
4 - 12
5 - 20
6 - 30
etc...

This is not an exact metric, but gives one feel for how complexity tends to "fold on itself".
     

All of the above and more (1)

huckamania (533052) | more than 8 years ago | (#15315372)

Whatever analogy you've just given, PLUS,

Having to share resources with other programs, threads, drivers...
Having to deal with sudden power loss, bad hw, actual bugs...
Having to deal with multiple cpus, connectivity, scalability...
Having to deal with malformed input, lax standards, bad guys...
Having to deal with legacy code, buggy libraries, the STL...

The only person I can ever explain anything to is my Dad. We learned C++ and Java together although he has about 40 years of experience in computers.

I work in security, have worked for Network Associates, Symantec and two other security related companies. When I try to explain something, I usually start at the problem end. Explaining why it is such a problem. About two minutes into that, they don't want to know the rest. Saves me the trouble.

As them how to use a traffic light (2, Insightful)

thecampbeln (457432) | more than 8 years ago | (#15315496)

That is what I do. "How do you use a traffic light? How do you determine if it's safe to drive thru the intersection?"

With this, I (almost) always get "If it's red, you stop. Green, you go." and which point I interrupt "And yellow (or orange for you Aussies out there)." It's about here that they start to think about it. Then I ask "What if it's raining?" quickly followed by "What if it's the first rain of the year?" and shortly thereafter followed by "What if you see someone else running the light in front of you?" I then explain that if I were writing a program to do something as "simple" as deciding if it's safe to go thru a traffic light, I'd have to think of ALL of these issues, plus everything else that could ever possibility happen while traversing an intersection. If I manage to miss something, it becomes a "bug" in that program.

In my experience, people pretty much "get it" with this analogy. Course, YMMV...

Good one! (1)

drenehtsral (29789) | more than 8 years ago | (#15315628)

I think that really does it! I (count my lucky stars) rarely have to deal with non-techies in an official work capacity, but the world still abounds with them, and they seem to divide into two categories, those who are like "Hey, wow, you can program a computer! You must be a genius!" and those who are like "so, you just tell the computer to do this, and then that, and you're done!" (those who imagine that every programming language has a "do-what-i-mean" statement.

Explain by example (2, Insightful)

Aceticon (140883) | more than 8 years ago | (#15315982)

When i'm discussing a request for implementing a new requirement or changing an existing requirement with the non-technical person making that request, a trick i usually do to show the complexity of apparently simple requests is to right there, present the high-level (eg. design) logical steps on how we would implement that request.

Non-technical people will understand the complexity of doing something when they follow you through the sketching of the process of making a solution that does it. For example, if you are asked to change a form so that a free text input field becomes a pull-down with a number of options you can:
- Ask them if the list of options is fixed or if an application administrator can change them
- If it's fixed, then it's easy to do, otherwise:
- Explain that you have to store those options somewhere. Maybe you already have a database, so explain that you have to add storage tables to the database, then add code to the application so that it can load and save that information to and from memory. Also explain that you have to pre-load some sensible default values into the database so that the application works out of the box.
- Since they want that some administrator can change it at runtime, figure out if said administrator is a developer/dba type of person or not. If not, explain that to allow an administrator user to change those values you have to extend your administrator interface, which means adding menu entries and one ore more new pages.
- Also figure out what are the rules (if any) that constrain the values that the administrator can configure for the pull-down. Depending on the complexity of the rules you might want to follow through into how you would do it, for example, if the rules are based on other values in the database which can also be changed by an administrator:
- Explain how you have to add code to retrieve and process the needed values so that you can check that the rules are not being broken, and that you also have to change the administrative interface for those other values so as to make sure that when they are changed or deleted, the values in the pull-down box do not become invalid.
- ...

The point here is that most non-technical people which actually use computers understand concepts such as memory and storing "data that cannot be lost when the application stops" (persistent data) somewhere other than memory. They can be made to understant the basics of a relational database: "a place to store data which has tables - a bit like excel tables - one table for each kind of information" (not exactly it but close enough) and they can usually follow a logical chain of steps (eg to show the data in the interface we have to get it from somewhere, since it is configurable, we store it in the place where we put the data that can be changed by the program but must be preserved even when the application stops).

Try and stay away of techie words and expressions ("We're gonna have to persist that data to our relational database and that means creating new tables, adding new data objects and changing the Hibernate mappings"). Instead assume non-techies are ignorant but not stupid ("We have to store that data in the database so that we don't loose it when the application stops. This means we have to configure in the database the tables where the data is stored and also have to add support in the program so that it can load that information into memory and use it").

Also, simplify:
- Don't try to be overly exactly - for a non-techie is enough to say you have a "database" no need to say it's a "clustered configuration of a <insert-brand-here> relational database".
- Don't go into deep details - you "configure the place in the database to store the data" no need to say you're "extending the tablespace, creating new tables, adding foreign keys to the related tables, and setting up a couple of indexes to speed up cross-referencing"
- Try and tune your words to the audience - for some people you can say you're gona have to "change the JSPs" for others your "changing the templates for our web-pages" and for others still "you're changing the part of the program that generates the pages shown in the browser". If their eyes glaze over you're probably being too technical, if they look impacient you're probably being too simplistic - that or they're on drugs, but just different ones ;)

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>