Friday, May 09, 2003

Hearse and Buggy, Part III

Finally we come to the first word in the title of this three-part series. The sad fact is that software programs don't last forever, and eventually it's time to have them be adopted by your uncle with the farm, so there's room for them to run around...

More bluntly, software sticks around too long. In fact, there are two major failure modes here:

1. Software that should die doesn't. This is exactly the cause of the Y2K crisis: software that was written decades earlier, by programmers who couldn't imagine it would still be in use in the year 2000.

2. Software that dies too young. This is how data gets stranded, when applications that are the only way to access a particular data format fade away, possibly because the company that produced them lost interest or disappeared.

As software creators (and buyers!), we need to start thinking about the role of a piece of software in an ecology, and what happens at the end of the lifecycle. We should be designing in graceful exit strategies, and we should be building in guarantees that the data will live beyond the application.

In a funny way, then, bugs may help out with this. As a software artifact becomes more complex, as it inevitably will, exponentially more bugs will be introduced. Eventually, the bugs will be so numerous and so irritating that the customer will demand to move to a new target, thus giving innovation a chance. Just like when a tree falls in a forest (whether anyone hears it or not), and the sunlight suddenly reaches the floor, illuminating all sorts of seedlings reaching for the light.