From Boards to Bridges: The Case for Software Engineering

January 5, 2010 at 5:43 pm 12 comments

Barb and I are just leaving (we hope! serious snow here!) Rochester, New York where we were visiting Rochester Institute of Technology (RIT) as guests of Paul Tyman.  Barb showed high school teachers and faculty interested in outreach some of her favorite toys and nifty ideas for teaching CS to high school students.  (We made it through security with a Pleo, Pico Cricket, a Scribbler, and a Lilypad.)  I gave a talk on meeting the computing education  needs of non-computing majors.

One of the RIT faculty, Axel Schreiner, said that he had no problem with non-computing professionals building scripts and spreadsheets for themselves.  He was very concerned that these end-users understand why such approaches did not scale and were not robust. He had an analogy that I thought worked well for explaining why real software engineering was necessary.

Imagine that you have a stream that you have to cross on an occasional basis.  You might put a board across that stream to get to the other side.  That board will work perfectly well for a lot of the time, maybe even most of the time.  That board is a script that a user might write up to solve a simple problem, to do a one-time task, to clean up some data, or to draw some graph.

What if you want to cross that stream more often, or even regularly?  That board will wear out.  You can put up a replacement board, so a series of boards might work just fine for you.  Maybe putting down a board each time one wears out is a reasonable cost instead of doing something more serious.  The script isn’t all that stable nor robust.

Now let’s imagine that you need to start carrying some more serious weight across the stream.  You might lay down two boards next to one another.  That doesn’t really work, as you’ll soon find out.  The boards separate, or things fall between them, or they still can’t bear the weight.  The script doesn’t scale.

At some point, you may decide that you really want a bridge, something solid and robust that you can build once and basically forget about because it just works so well for so many purposes.  Once you’ve decided to build a bridge, you might as well make it pretty, even beautiful.  If you’re going to pay the cost for engineering, the increment to have something elegant and beautiful is worth it.

Axel convinced me that this is an important learning objective for end-users: To realize when they need more than an end-user solution, more than a board across the stream.

Entry filed under: Uncategorized. Tags: , , .

CMU’s Hybrid Education 2.0: Better than a classroom Rethinking Science Education as Contextualized

12 Comments Add your own

  • 1. Erik Engbrecht  |  January 5, 2010 at 9:16 pm

    That is a good analogy, but I think it needs to be reversed as well…sometimes the user really just needs a board, and trying to build him a bridge is just a waste of time and money. Software engineers need to be able to right-size solutions. The answer to every problem isn’t a four tier JEE web application with hot offsite backup and instant failover with a seven figure annual maintenance budget just to keep it running, much less enhance it.

    Such things make users realize just how fond they are of their board.

    Reply
    • 2. Mark Guzdial  |  January 6, 2010 at 8:59 am

      Agreed, Erik — I think that’s Fabio’s point as well.

      Reply
    • 3. Darrin Thompson  |  January 6, 2010 at 1:49 pm

      I had the same idea.

      One thing I’ve noticed though, business people tend to accumulate a lot of boards. And when I say a lot, I mean a harmful and dangerous environment where damage is done to their business.

      They only choice they (think they) have is build the one great integrated unifying thing, or pragmatically just live with what they have and take the hits when boards fail, or people fall of the boards.

      Neither choice is good.

      Reply
      • 4. Erik Engbrecht  |  January 6, 2010 at 5:40 pm

        I would rephrase that as “the only choice they are usually given is build one great integrated unifying thing…” I think this idea originated with technology professionals, not users. Note that I’m explicitly saying “technology professionals” instead of “computing” or “software.”

        I also think technology professionals tend to exaggerate the dangers of boards. Consider the following paper on user behavior and security:

        Click to access nspw2009-herley.pdf

        The reality is that users are often living with a lot of risks. Remember, there’s a good chance that before the user had his board, he was fording the stream, so no matter how dangerous the board is it has reduced both his effort and his risk. The remaining risk is clearly worth it, while the cost of a bridge often is not.

        Reply
  • 5. centennialcollege12  |  January 6, 2010 at 7:44 am

    Nice post! Your post have good examples for a side of software engineering education. I agree to your points but you can still add more to have refine, catchy and enthusiastic ones to hold it well.

    Reply
  • 6. Fabio de Miranda  |  January 6, 2010 at 8:23 am

    In software, in some cases the guy who put an improvised board might have happened to place a board that can carry all the weight you want and perfectly solve the problem. Overengineering sometimes is just as bad, because you solve the same problem but at a higher cost

    Reply
  • 7. Alan Kay  |  January 6, 2010 at 4:02 pm

    Per Darrin

    Boards are not bio-degradable (or other-degradable) so the analogy is not a very good one here.

    Just as a brick doesn’t suggest the arch, the board really doesn’t suggest a real bridge. So the general unsophisticated hacker will tack boards onto boards when improvements are needed, rather than draw on the idea of “bridge” which they are not at all aware of.

    In the physical world forces and masses are strong enough to pull down many such kludges, and these catastrophic failures are real motivators to find better ways (including by just learning more about better ways that might already have been invented by others).

    But the almost 0 “mass” and almost 0 “forces” in computers allow really awful stuff to not quite fail — which would not be such a bad thing if the terrible stuff was invisible and didn’t distract and tempt.

    One way to look at this is that most software is in the middle of a long slow crash while making it hard to think about anything else.

    This thesis is very easy to substantiate via the overwhelming evidence exhibited in most software systems done by most programmers.

    Cheers,

    Alan

    Reply
  • 8. Greg Wilson  |  January 6, 2010 at 11:02 pm

    Unfortunately, a lot of end-user programmers don’t know enough about software to recognize or understand the differences between boards and bridges, which makes it difficult to convince them that they need something other than what they already have (in either direction).

    Reply
    • 9. Erik Engbrecht  |  January 7, 2010 at 12:10 am

      When the consumer of a good can’t tell the difference between two products, are they really that different?

      Trust me, I feel the frustration. But the common arguments for a professionally developed solution don’t match up with practice. We claim to that we’ll build something robust and scalable and maintainable that meets the requirements, and what we deliver tends to be none of those things.

      There is the implicit assumption in software engineering that the domain of building software is inherently more complex than the domain of the problems being solved by the software. I think this assumption is often dead wrong. Why should they trust us to be able to implement solutions in their complex, intricate area of expertise when we know nothing about it and have to be spoon fed every detail? Because we have such a good track record of success?

      Reply
      • 10. Darrin Thompson  |  January 7, 2010 at 11:08 am

        My theory based on read Deming and friends is that these users can’t really decide what to build. Their problem domain is filled with accidental complexity to begin with, so they lose the custom software game before they begin.

        If they would remove the accidental complexity and reduce their problems to inherent complexity only, they might not need custom software. Or possibly they will discover something custom they can approach with clarity.

        Reply
      • 11. Erik Engbrecht  |  January 7, 2010 at 12:20 pm

        Darrin,
        My personal observation is that adding “professional software engineering” to the mix is far more likely to increase the accidental complexity than to reduce it. The norm is for the software engineer (or business analyst or whatever) to rely on the user to remove any accidental complexity from the domain, because the norm is that the software engineer has very little understanding of the domain.

        There certainly are exceptions where projects have someone who thoroughly understands both the problem domain and software engineering, but they are rare. Most career incentives focus on either specialization or transition to management. Very few encourage being multidisciplinary.

        So my point is that I don’t think in general a credible claim can be made that users should trust software engineers to be able to identify the essence of their problems and then craft software to address them. I think as it stands today, quite the opposite is true. Software engineering as a profession continues to thrive despite this fact because there is significant economic incentive to making convoluted things faster and less labor intensive. But I don’t think that’s a sustainable model.

        Reply
  • 12. Alan Kay  |  January 6, 2010 at 11:14 pm

    To use physical world analogies, there are no building codes for doghouses (as far as I know) but doghouses don’t scale, so it is important for there to be building codes for larger structures whether built by pros or amateurs.

    Heh heh, it would in interesting to build in a half life for software, so it can’t hang around and has to be reimplemented from scratch periodically.

    Cheers,

    Alan

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trackback this post  |  Subscribe to the comments via RSS Feed


Enter your email address to follow this blog and receive notifications of new posts by email.

Join 9,052 other followers

Feeds

Recent Posts

Blog Stats

  • 2,031,109 hits
January 2010
M T W T F S S
 123
45678910
11121314151617
18192021222324
25262728293031

CS Teaching Tips


%d bloggers like this: