Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Explaining Complexity in Software Development? 202

Posted by Cliff from the just-don't-have-the-right-words dept.
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.'
This discussion has been archived. No new comments can be posted.

Explaining Complexity in Software Development? More

Explaining Complexity in Software Development?

Comments Filter:

  • I don't (anymore) (Score:4, Interesting)

    by yagu ( 721525 ) * <yayagu@[ ]il.com ['gma' in gap]> on Thursday May 11, 2006 @07:36PM (#15313732) Journal

    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) (Score:5, Funny)

      by Ithika ( 703697 ) on Thursday May 11, 2006 @07:47PM (#15313812) Homepage

      (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) (Score:5, Funny)

      by Rosco P. Coltrane ( 209368 ) on Thursday May 11, 2006 @07:49PM (#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.
    • 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) (Score:3, Informative)

      by Sigma 7 ( 266129 )

      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 m

      • A slightly better explaination is that it's more like building a car, "hot-rod" style.

        ...or like building a bike on American Choppers. At that point I worry that my boss would take things too seriously, grow a giant moustache, and start yelling at all of us to go get some work done.

        Seriously though, the analogy is pretty good. It gets better when you look at things like body work where parts have to be designed before they can even be fabricated.

  • My favorite: A Christmas Carol (Score:4, Interesting)

    by Marxist Hacker 42 ( 638312 ) * <seebert42@gmail.com> on Thursday May 11, 2006 @07:46PM (#15313802) Homepage Journal
    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.
    • Not only that, but 250 copies of A Christmas Carol where if you get a word wrong, the whole novel may crash and burn.
      • 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.
    • 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 (Score:5, Funny)

      by Rosco P. Coltrane ( 209368 ) on Thursday May 11, 2006 @08:12PM (#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.

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

      That analogy can be carried further. If you change a single letter in the Christmas Carol, probably nobody even notices, unless it's something like misty

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

  • madlibs! (Score:5, Insightful)

    by conJunk ( 779958 ) on Thursday May 11, 2006 @07:49PM (#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! (Score:4, Funny)

      by Rosco P. Coltrane ( 209368 ) on Thursday May 11, 2006 @08:03PM (#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.

    • I had to actually do this!!!

      I just layed out two very short examples of spam and good email, 20-30 words each, and had him identify which was the spam. Easy enough and the interaction got me 30 seconds into the presentation and he was still with me.

      It got a bit trickier when I hit the conclusion that I was not using Bayes theorem for identification of spam but to qualify logged events in a 37GB log file. Talk about bloat! But he understood well enough that my identification of a word/phrase worked the

  • I say something like... (Score:2, Informative)

    by voxel ( 70407 )
    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 t
    • 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.

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

    • Oh boy (Score:3, Funny)

      by woolio ( 927141 )
      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 c

  • Stupid quote (Score:3, Insightful)

    by 2nd Post! ( 213333 ) <gundbear.pacbell@net> on Thursday May 11, 2006 @07:53PM (#15313861) Homepage
    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.
    • >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 re
    • Please, whatever you do, no more software-car analogies!!!!

    • At first I was thinking the clay idea wasn't too bad, especially when you consider how much clay will move when you fire it. This means that high precision products made of clay cannot be manufactured without some extra steps to polish the post-fired product to tolerances.

      But you more you talk of malleability the more I think of Silly Putty. Sure you can shape it to stand up tall, but it creeps and falls over given time. Which is a horrible analogy to software because it implies that software isn't stab

      • Software isn't complex. Software is actually really simple once you understand the language(s) involved. To state the Software Engineering is complex means you don't understand the concept. There might be a lot of steps to it, but it's never hard.

        I think you are confusing software with code. Writing code is not very hard. Software is a purpose manifest in code, which is difficult. In the face of choosing which algorithm to write actually writing the algorithm itself is not that difficult. As computers bec

  • Depends on the audience (Score:3, Interesting)

    by nosredna ( 672587 ) on Thursday May 11, 2006 @07:55PM (#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 (Score:3, Funny)

    by sedyn ( 880034 ) on Thursday May 11, 2006 @07:56PM (#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.
    • It's too bad lawyers DON'T write things in a strict language. With syntax checkers.
      • 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
        • 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.

          • 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 completel

            • 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.
              • I think there are different types of law. A VERY precise language should be required for contracts, for instance.

                That's a nice idea, but in practice it just wouldn't work. Courts have explicitly rejected the notion for a number of reasons:

                • the number of things you can contract to do is unlimited. if you can think of it, you can contract for it. about the only exceptions are violations of an inalienable right or public policy.
                • many, perhaps most contracts are not drafted by lawyers. a lot of contracts
                • Limit things to written contracts, leases, etc. I didn't suggest having MORE contracts, just making the formal ones a little, well, clearer. If it were done properly I think you could set it up so that they were easier to write, not harder.

                  For example, I recently reviewed an IP transfer contract. The terms stated that party A would pay party B $50,000 for every $1,000,000 of gross sales. 5% right? Nope. Anywhere from 0% up to 5%, depending on exactly how much gross sales are. That sort of misleading
        • He laughed because I would estimate that 100% of all legalese is designed to mitigate the risk of "user error", and as we all know in computing, "user error" is the one thing you cannot truly design around to completely mitigate all risk in the system. Being a lawyer and writing legal documents is more akin to playing with statistics than it is writing computer code. In other words, there's always that 0.01% chance that a hole could be poked somewhere in the legalese, no matter how well-written the legal do
    • To be honest, this way of thinking sounded better when I first started, and I'm kind of disapointed with my end product.

      Ah, now I know you obviously must be a programmer.

  • My analogy (Score:5, Interesting)

    by Rosco P. Coltrane ( 209368 ) on Thursday May 11, 2006 @08:00PM (#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 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.
      • In other words, the better the kitchen, the more reliable the dishes will be, and the faster the cooks will be.
      • 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.

        That's only true if the function is a separate piece of code. I've been in enough situations where noone really has the overview but it turns out that some code isn't being used at all anymore, often because the entire function/module has been depreceated and then dea
        • I'm not trying to suggest that an appropriate model is to always add every feature anybody thinks of. There are very valid reasons not to bloat your code like that, to keep it easier and simpler to maintain, test, audit, secure, etc.

          But there is still a difference there. Perhaps I could best explain it as: You can never take your existing software, spend time/money optimizing it, and somehow make it cost you less to produce a million copies of the software.

          (More USERS, maybe, but not more copies of the s

    • Re:My analogy (Score:4, Insightful)

      by Mignon ( 34109 ) <satan@programmer.net> on Thursday May 11, 2006 @09:38PM (#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.
      • 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.

        So that's where my boss goes for lunch all the time.

    • 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?

      Altern
    • 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
    • Before I changed line of work (I'm not a computer professional anymore thank goodness)

      Wow, no wonder you changed your line of work. Personally, I like using the Gantt charts to choke the tasters, then blame it on the chief cooks so you can go get some actual work done.

      I realized that comment was in bad taste (and probably tastes bad). I would never actually do those things or otherwise condone workplace violence. (It's such a pain to post non-AC)

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

    by silvermorph ( 943906 ) on Thursday May 11, 2006 @08:00PM (#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.

  • Software as a machine (Score:5, Insightful)

    by Profane MuthaFucka ( 574406 ) <busheatskok@gmail.com> on Thursday May 11, 2006 @08:14PM (#15313998) Homepage Journal
    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.
    • 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.
    • -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?

      I liked your examples, but there is another side to comment on.
      What about approx. useable life (mostly guesses + personal experience)?

      Airplane - 10-20+ years
      Car - 5-10+ years
      35MM Camera - 3-10 years
      Transistor radio 2-5 years
      Mouse trap - 1 year

      assuming everyday use.

      Planes and cars get
    • I think that vastly oversimplifies the complexity of building a real machine.

      A "line of code" contains 3-10 operations, each of which require no further elaboration -- they are perfectly discrete, ideal parts that always work exactly the same way, even when used in completely different situations.

      For a real machine, on the other hand, each part requires a complete design and build cycle of its own. How many "operations" would it take to describe the shape and material of a single part? Hundreds if not t

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

  • design and mapping (Score:4, Insightful)

    by Darth_Burrito ( 227272 ) on Thursday May 11, 2006 @08:34PM (#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?
  • 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 o

  • why it's not like building a house (Score:3, Insightful)

    by davez0r ( 717539 ) on Thursday May 11, 2006 @08:38PM (#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.
    • 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.

      Strangelly enough i have two counter arguments at different levels:

      1) Purelly in a programmer as coder sense, a good programmer will do the same thing EXACTLY twice

  • Why is software complex? (Score:2, Interesting)

    by maxume ( 22995 )
    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?
  • 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.
  • 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.
  • 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. (Score:3, Interesting)

    by Kaenneth ( 82978 ) on Thursday May 11, 2006 @09:34PM (#15314461) Journal
    "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."
    • In one of the Red Mars books, a scientist was dedicating the remainder of his life to solving the problem of human immortality, and there's a passage in the book that's very similar to what you just typed. How there are millions of miles of blood vessels, thousands of chemical reactions, millions of brain cells all firing at just the right moment... and the more you know about how the human body works, the more amazed you are that it works at all.

      I think that applies to everything. I'm constantly amazed t

  • It's not horribly complex. (Score:3, Insightful)

    by SanityInAnarchy ( 655584 ) <ninja@slaphack.com> on Thursday May 11, 2006 @10:36PM (#15314760) Journal
    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.
    • 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 translat
    • Well, part of it is that there are 25 millions line of code, you just don't interact with them. Recovering from an error is like a red light flashing in a 747, except you need to build in the intelligence to handle it. And while you have multiple redundant systems for physical failure, you only have one application (although it can have multiple threads etc) so there's no "ignore and continue", unless it's a specificly handled condition.

      The second part is that the computer will do *exactly* what you tell it
  • 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 obstac

  • As them how to use a traffic light (Score:3, Insightful)

    by thecampbeln ( 457432 ) on Friday May 12, 2006 @01:19AM (#15315496) Homepage
    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...

  • Explain by example (Score:3, Insightful)

    by Aceticon ( 140883 ) on Friday May 12, 2006 @04:17AM (#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 gon

  • So, you have tried to explain to other intelligent, competent techies why programming is so much more complex than what they do, but you can't seem to convince them, eh?

    Have you considered that maybe, just maybe, you are wrong? Maybe programming isn't harder than hardware design, or mechanical design, or mathematics, or physics? I mean, if it were, it would be a really convenient excuse, wouldn't it? "Your OS crashes so much because software is really complex." "You got infected by this virus because

  • Try web development (Score:3, Interesting)

    by SmallFurryCreature ( 593017 ) on Friday May 12, 2006 @05:02AM (#15316073) Journal
    It is very hard to get across the difference between a properly coded site and one made by some kid who knows some scripting language.

    The simplest is browser compatability. Does the site owner care? Well yeah if you can get their head around the fact that if the site is IE only they will be losing a percentage of customers. It is very odd. Supermarkets understand they need an extra wide register for people with special needs. They know they need staff on hand to help disabled people because no supermarket can afford to turn that tiny percentage of people away who need help. Most brick and mortar stores would be horrified to learn that their to narrow door would loose them say 5% of visitors. So why is it acceptable on the net?

    Then their is the proper use of standards. It ain't just that you got to use CSS but more that you got to choose a standard way of doing things. Use font tags if you want BUT then ALWAYS use them. Not some horrid combo of font tags, inline css, external css and included css. Makes it a pain to figure out what the fuck is supposed to affect what.

    Finally there is the coding itself. Every damn time I get called into to fix a site I find that some kiddie has hacked it together and totally forget to do any kind of error checking let alone proper security. Most just take values straight from the user and insert them into sql queries. And why does anyone create a login page for the site CMS without https being enforced?

    I seen code that would make you weep. Yet the site works doesn't it. Well no that is why I am called in but it then is very hard to explain why you need a week to upgrade the site before you can even start fixing things. (Note that the sites are generally so poorly designed that the original builders are no longer willing to support it wich is when I get involved).

    But how do you explain to the customer about the difference between bad code and good code.

    Recent page had a simple form for the usual add, update and deleting of a record. The code contained no functions and had the most horribly arranged IF/ELSE statements you could imagine (IF(user_logged_in) {ALL THE CODE} else {error_msg} EWH!!!!!

    Worse it had the HTML/FORM 3 times for each type of action. Except that they were practically the same. Just an empty form for add, a filled in form for update and again a filled in form for delete. 3 Times the same HTML all because the idiot never grasped the concept of functions. (He didn't use them anywhere in the code).

    Yet how do you make this clear to the customer. If you know the answer please tell me.

  • I would keep on quoting No Silver Bullet and expand onto the rest of the "complexity, conformity, changeability, and invisibility" mantra.

    Especially the invisibility part is usually easy to grasp.

    One textbook also made a comparison with a steel bridge: if the bridge crashes the damages are huge, if software crashes a boot can usually solve the situation temporarily. Also, civil engineers are rarely asked to move the almost completed bridge mile upriver and turn it 90 degrees by the lengthwise axis.
  • Try it in terms of decision tables:

    Each condition requires a true/false decision, plus an associated action.

    Rule1 y y n n
    Rule2 y n y n

    Actn1 x - - -
    Actn2 - x - -
    Actn3 - - x -
    Actn4 - - - x

    Therefore the mathematically possible combinations = 2^n *2. (The example shown is 2^2 * 2 = 4 * 2 = 8.) A two rule program has 4 mathematically possible conditions and 4 mathematically possible outputs, therefore the programmer has to attend to 8 elements to cover the complexity of the program. With five condition

  • Complete specification (Score:3, Insightful)

    by try_anything ( 880404 ) on Friday May 12, 2006 @02:01PM (#15319603)
    You know the annoying kid you knew in college who would repeatedly interrupt every discussion demanding definitions of all the words being used, and who would argue endlessly about flaws in the definitions so that you couldn't really talk about the topic you wanted to? Imagine you're writing a book, and that guy has to personally approve every sentence.

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close