Why software is different from hardware

I enjoyed reading through this programmer's diary discussing the work that Art Cabral is doing to try to update an old application so that it runs on more modern systems.

Now, Seahaven Towers is an amazing piece of software; I remember running it back in 1991 or so, and being amazed that, year after year, the program "just worked" on each new Mac and each new version of Mac OS that I tried it on.

And Cabral's diary contains some great information about how he got the program to that level of quality, describing his attention to detail in areas such as string handling, graphics, and character sets.

But it's a fine example of why software can't just be put in a box and declared 'done'. As Cabral observes:

A lot of 3rd party tools were used to create Seahaven Towers 2.0. Robust, stable tools they were, certain to be around for a very long time. Let's see - CodeWarrior for Windows (gone), CodeWarrior for Mac (gone), Adobe GoLive (gone). There were others that disappeared as well. Now Apple takes away Rosetta for no technical reason I've been able to fathom. It's been said (and I can't recall the attribution) that hardware architectures last a maximum of 3 years and software architectures last around 30 years. Apparently that last part is no longer true.

Well, 30 years is a long time. Even 20 years is a long time. I remember using CodeWarrior myself, in 1996, and it was indeed a nice programming tool.

Operating Systems change, compilers change, APIs change, frameworks change, and there's no standing still on the treadmill of software progress. If you aren't routinely attending to your program(s), building them and running their tests and keeping up with changes in their environment and staying alert for upcoming shifts in the underlying foundations upon which they are built, you'll end up with a program that no longer works, and no idea about how much work it's going to be to get it to run again.

I don't know a way to eliminate pain, but I do believe that Continuous Integration systems can make this pain substantially less. By automating robots to do this boring testing for you, you can spend less time discovering and cataloging these sorts of things, and more time planning how to deal with them.

At my day job, I work on the maintenance and upkeep of a 17-year-old piece of software, and I'm also involved with a 15-year-old open source project. In both cases, there are substantial bodies of test suites that are nearly as old as the product itself, and ongoing investments in tools and laboratories of robotic computers slaving away, verifying over and over again that "things still work" (yes, we have to check this, all the time!)

There's great value in working on old software: it's survived the test of time, it's demonstrated enduring value, it's acquired a lasting community of adherents. We know the value of such software, and so we work hard to keep it alive.

Best of luck to the Longwood Wizards Guild!