From Boards to Bridges: The Case for Software Engineering

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.