Volatile Software

I want to use my fifteen minutes of fame on The Listserve to rant about something that's close to my heart: the stability of the software I use.

NOTE: This is written for people who create software.  If you don't do that you probably won't find this very interesting.  Sorry!  Maybe you could read Text from Dog if you haven't seen it already?  Either way, have a nice morning/afternoon/evening!

The Situation -------------

Every time I get a new computer, I go through the same song and dance:

1. Look at what programs and packages I have installed on the old computer. 2. Install these programs on the new computer. 3. Copy over my configuration files from the old computer to the new one. 4. Spend the rest of my day fixing all the things that broke because I'm using    a newer version of program X.

Step 4 is always the most painful part of getting a new machine.  Always.

Without fail I spend several hours tweaking configuration files, adjusting my workflow, and so on because I've upgraded to a new version of foo which doesn't support option X any more or requires library Y version N+1 now.

Getting a new computer should be a pleasant experience!  The unboxing from the sleek packaging, that "new laptop" smell, the nostalgia of the default desktop image.  Why does this horrible step 4 have to exist and how can we get rid of it?

The Divide ----------

I've noticed something interesting lately: I can categorize almost all of the software I use into two distinct groups:

* Software that breaks pretty much every time I update it (e.g. weechat,  offlineimap, Clojure, many Python packages, Skype). * Software that almost never breaks when I update it (e.g. Mercurial, git,  tmux, Python, ack, zsh, Vim, Dropbox).

Software that falls in between these two extremes is surprisingly rare.  There seems to be a pretty clean divide between the two groups.

This makes me think that there's some special attribute or quality of the second group (or its authors) which the first one lacks.

Brokenness ----------

I think it's important that I nail down what I mean by "breaks" or "is broken". I don't necessarily just mean the introduction of "new bugs".

When I say that a program "breaks", I mean:

* When I update from version X to version Y of a program, library, or language... * Without changing my configuration files, source code, etc... * The resulting combination doesn't work properly

In effect, I'm saying that "breaking backwards compatibility" means "the program is broken"!

This may be a strong statement, but I stand by it in most cases.

Backwards compatibility matters!  Every time someone makes a backwards incompatible change in a program or library, they cost the world the following amount of time:

   Number of people          Time it takes each person    using that part of      X    to figure out what changed    the program                   and how to fix it

Often this can be a significant amount of time!

The Process of Updating -----------------------

When pointing out a backwards incompatible change to someone, you'll often get a response similar to this:

   "Well, I mentioned that backwards incompatibility in the changelog, so what    the hell, man!"

This is not a satisfactory answer.

When I'm updating a piece of software there's a good chance it's not because I'm specifically updating that program.  I might be:

* Moving to a new computer. * Running a "$PACKAGE_MANAGER update" command. * Moving a website to a bigger VPS and reinstalling all the libraries.

In those cases (and many others) I'm not reading the release notes for a specific program or library.  I'm not going to find out about the brokenness until I try to use the program the next time.

If I'm lucky the program will have a "this feature is now deprecated, read the docs" error message.  That's still a pain, but at least it's less confusing than just getting a traceback, or worst of all: silently changing the behavior of a feature.

Progress -----...