hide all comments

Programming

200 year software

June 23, 2008 22:40:00 +0300 (EEST)

A customer from Norway heard from a friend of a project with software dating back several decades (not as uncommon as you might think). He sent me a link to, and a request to blog about, an article on Software that Lasts 200 Years, written by Dan Bricklin. Since Dan is one of the creators of VisiCalc, he ought to know a thing or two about the topic. His main thesis is that software for certain tasks in society (libraries, public records etc.) needs to be built, maintained and indeed thought about in a different way from today's software: as infrastructure akin to roads or bridges.

Dan Bricklin is always interesting, I've found myself coming across his site several times. I don't really have any great insights on what he says in the article, so I'll just add some thoughts on a few bits. I like his comment that open source fans should concentrate on getting trains to run on time rather than persuading railways to run on Linux. The basis of open source was that it's nice if people who write software have access to the source code of other software, not so much about making software and giving it away for free to people who will never look at the source code. Both are fine aims, but sometimes these days the focus is only on the secondary aim and people forget about the primary aim.

Dan is refreshingly realistic in accepting that there will be multiple ways to achieve "software as infrastructure": companies, government, open source communities. Some of his views seem a little naïve, e.g. the idea that licensing professionals is just to improve quality: I think economists generally say an important function of licensing is to restrict entry, thus increasing scarcity and helping justify high prices for existing practitioners. Similarly his thoughts on standards bodies assume they only work for the common good, not to restrict competition or force competitors to compete on existing companies' terms. (I'm deliberately pointing out only the other side of the coin here; the truth includes both sides.) In contrast to what he says (admittedly back in 2004), major enquiries have indeed been held when software has failed, but since the parties involved are mostly private companies rather than government (unlike for bridges), they aren't often public.

Those are some of my opinions, but I'm sure Dan has better grounds for his: read the article to get the full picture. (Mind you, I suspect a good economist or analyst could do a lot better than either of us: if any readers have good links, add a comment!).

I still occasionally use the first piece of commercial software I wrote (a sound editor for Casio's CZ range of synthesizers) and the first programmer's text editor I used at work (Intel's aedit) -- both from around 1986. People born in that year have now graduated from university -- a sobering thought. Not just because of how much it dates me, but because of how little has changed. That university graduate has certainly changed and matured a lot more in 22 years than our industry or the tools we use.