Tech Stuff - Hammer Theory of Everything

This is a, not entirely, serious opinion piece (call it a rant if you are in a mood to be unkind) about backward compatability and having to learn new stuff to do the same stuff.

The last time we used a hammer it worked the same way it did the first time we picked one up, all those years ago. The technology had changed (the head did not threaten to fly off and the shaft felt unusually robust) but it worked the same way. You picked it up and whacked things.

We use a lot of software to do important (well, we think so) stuff. We do some research to figure out the best (in our normally limited opinion) tool for the job. We learn enough about the tool to do the job. And when the task is complete we breathe a sigh of relief and move on to the next task (that's why we wrote many of these pages). If we change our functional requirement then we, obviously, have to upgrade our knowledge of the tool. But if our requirements do not change we expect the tool to keep doing its job. (Some tools, very few, are more strategic and we take longer to evaluate them, longer to learn them and use them, perhaps, daily. We can handle occasional changes because our knowledge is constantly being refeshed through use.) For the majority of tools, however, we have a usage-centric mindset.

If you are a developer of software, of necessity, you use it daily, think about it daily, fiddle with it (highly technical terminology) daily. Your mindset is very different to the majority of users of that software - it's tool-centric not usage-centric.

We have not changed the functional requirement for our web server almost since we first had a web site. We wrote a configuration file for Apache 1.x around 1997 when we adopted it as our chosen solution after migration from a previous implementation which shall remain nameless (OK, so we forget what it was) and it lasted, essentially without change, until we were forced to move to Apache 2 (for IPv6) close to 15 years later. (And we were lucky because we went straight to Apache 2.4 so we only had to make one change, had we moved earlier we would have had a 2.x -> 2.4 change as well.) We loved Apache (and still do) because we could take a new release, install it and it worked. A few less bugs and no hassle with the config file. Time after time after time. The point here is not to single out Apache and say it was good and is now bad, but to point out that the Apache Web server project has moved from being very pragmatic (usage-centric) to being purist (tool-centric). Why?

We should also note that because of the change we decided to look at alternative solutions. The Apache decision was close.

Both Python and Ruby have crossed their respective Rubicons (no pun intended) by making the non-backward compatible language jump (Python 2 to Python 3, Ruby 1.8 to 1.9 +). We also note that in Python's case the change was made in 2008 and legacy python 2 releases are still being made (and, in our opinion, will be for decades - it was originally forcast as a couple of years, max). Ruby has less of an established code base so may pull off the transition more quickly. Maybe.

We recall reading, apparently heartfelt, pledges of stability from both language founders in what appears like a dim and distant past. Both projects justified the change by claiming that language purity would be utterly destroyed (and consequently the sun may fall out of the sky) if the change did not happen. How come the purists (tool-centric) won over the pragmatists (usage-centric)?

Many, many years ago we worked with a guy who coined the term stiffware (now boringly referred to as legacy software) which loosly meant that the software/firmware/library was written by someone who had either left the company, moved onto new things or had otherwise (to paraphrase Dylan Thomas) gone gently into the good night.

Not only is there genuine resentment at having to revise something that worked to make it - work, there is the purely tactical consideration of finding a warm body that even knows what it does or understands the idiosyncratic style in which it may have been written.

Let's not even talk about about our own bête noir - the XHTML to HTML5 betrayal.

Apart from being curmudgeonly what's the point of this piece? When you are forced to invest time in re-learing what you already know you are not moving forward. By consuming time in re-learning what you already know it removes the time available for innovation. By consuming time in re-learning the past it removes the time available to consider the future. Only the big guys have the resources to squander on the past and still have effort in reserve. Long live the oligarchy (not).

And, as for the hammer, there were probably guys like us around complaining when someone added a handle to the hammer, three or so millenia ago.

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.