IT History Society Blog

It is possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as soap bubble?

December 2nd, 2008 by Paul Ceruzzi

alan_perlis(The quote is from the late Alan Perlis, #74 of his “Epigrams on Programming“).

I was recently asked for some advice on how best to present the history of software in the Computer History Museum’s timeline of computer history exhibit. I haven’t visited that facility for a while, but based on what I know of the people who work there, I am sure they are doing an excellent job. Telling the history of software – whether it be in a museum exhibit, book, or research paper – in not easy. Why? I wrote a little bit about this in my book, A History of Modern Computing. Although I devoted a chapter (Chapter Three) on the early history of software, several of the reviews  on Amazon.com were critical of the book because it didn’t deal with software!  Why did they feel that way, after I had devoted what I thought was a lot of space to the topic?

The problem begins with the definition. If software is the set of procedures by which one operates machinery, then it is as old as machinery itself. How to get a boat through a canal lock, for example. I’ve watched the National Park Service pass a boat through a lock of the C&O Canal in Washington, D.C., and it is a very complex algorithm that has to be executed precisely, or else the boat won’t go through the lock. But that is too broad a definition. Knuth would probably begin software with the calculation of the date of Easter – The first Sunday after the first full moon after March 21. Not an easy calculation at any time. Knuth says “There are many indications that the sole important application of arithmetic in Europe during the Middle Ages was the calculation of the Easter date…”(Art of Computer Programming, vol. 1, pp. 155-156).knuth

Last spring I noticed that although the New Testament story of Easter is clearly associated with the celebration of Passover, in 2008 Easter was on March 23, while Passover was on April 19-20. What would a software engineer say about this? I was told (by a Unitarian!) that the discrepancy had to do with the difference between “March 21” and “the spring equinox.” So it is a specification problem.

Or at least that is what I think Perlis would have said.

One more thing. As a museum curator, I find it almost impossible to show software in a museum. By definition it is everything that is not hard, so where are the artifacts?

2 Responses to “It is possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as soap bubble?”

  1. Sandra Mols Says:

    “As a museum curator, I find it almost impossible to show software in a museum. By definition it is everything that is not hard, so where are the artifacts?”

    This makes me think about discussions we had recently with Gerard Alberts and Tom Haigh at Lisbon at the SOFT-EU meeting. We then discussed on how software might well not be showable at all. If shown through lines of codes, you do not show the software per se in the how, when and where it matters, i.e. what it does, and how it does it. If shown in action while implemented on a machine, you show the software for sure, but also, to the non-expert’s eye, the machine in action, and mostly the finalised effect of the software but not what it does as a process. Also, replacing that software by another one, given the speed of machines, cannot be distinguished at all by a human observer. If you show a software for what it does and then alter it to make it fail doing so, to the non-expert, you do not show a flaw in software either, but rather suggest one in the hardware. Given that software cannot operate without platform, it is indeed quite tricky to show it off. The only way may be to return to a totally open machine, and a very slow one indeed, wherein if run a programme could show, but if you have thousands of lines of codes, that might take you a while to display a sophisticated recent piece of software…

  2. William Hugh Murray, CISSP Says:

    To the extent that software is ephemeral, it might well ought to be. That said, much of what we do with software should not properly be done by ephemera.

    One does not want one’s airplane, x-ray machine, or even one’s elevator, operated by “bubbles.”

    On the other hand, the line between what is “hard” and what is “soft” is itself ephemeral. It is the difference between what is bound early, resistant to later change,hard, and that which is bound late, amenable to later change, soft.

    This brings us back to requirements and specifications, specifically to include application and environment. Software that one writes for one’s own exclusive use in one’s own exclusive environment may well be ephemeral. However, the more sensitive the application and the more hostile the environment, the more demonstrable the artifact must be and the more persistent those properties which are demonstrated must be.

    To the extent that so much software is ephemeral, i.e., not reliable, it is largely because the requirements were never properly articulated or recorded.

Leave a Reply

Current day month ye@r *