The art of endless upgrading

There's a corollary to this: if you value your time, aggressively limit the number of components in your life.

We do this in tech by bundling up things: I don't have to worry about a certain cellphone chipset's lifetime because I just toss the entire unit after a certain period and replace it.

This model sounds like fun if it's your hobby.

In my world, however, spontaneously upgrading a library or a language runtime from one major version to the next will cause a bunch of websites to break. This is exactly what customers pay our company to avoid.

Because, in fact, the "continuous" model is a poor fit for software ecosystems unless your time scale is sufficiently long. If you don't care about downtime as measured in hours or days, go ahead and sync up every day. But if you care about downtime as measured in minutes or seconds, the continuous model isn't good enough, because at that scale software doesn't evolve continuously at all. It lurches ahead in sudden jolts, and each component lurches ahead on its own timescale, and only when you stand way back does the process look continuous.

The other problem with the "continuous" model is bugs. Software only lurches ahead on average; in practice any given patch is as likely to move you backwards as forwards. Three steps forward, two steps back. If I could be assured that every change in the Linux kernel was permanent and perfect, it might be worthwhile to run my websites off the latest kernel source HEAD, sync up every day, and fix bugs as they arrived. But in the real world, if someone commits a bug to the kernel source tree on Monday, and it breaks my site, so I work around the bug, and then someone fixes the bug in the kernel on Friday, and then I roll back my workarounds, I have just wasted hours of my life that I will never see again. I have churned my code for no net gain.

(Of course, you may ask: Why didn't I just fix the kernel bug on Monday instead of working around it in my site's code? Well, the Linux universe is too complicated for any of us to hold all of it in our heads: I can't fix kernel bugs, at least not on a timescale of days. So "this isn't the Apple II anymore; the universe is too big to patch the whole thing at once" is yet another reason why the continuous model doesn't work.)

It's just not that simple.

I think there are two different things happening here, which are not quite pinpointed. We have to work for both, but they are different kinds of work.

With physical things, you want them to keep doing the same thing, but they degrade themselves. With software, it just stays being the same, but you want to keep changing what you do with it.

Are there not rather different kinds of knowledge-work demanded there? With keeping things the same, you have a basically closed-ended aim -- you just gather more knowledge and you have it cornered. But with changing things everything is always open-ended -- what you will need to know seems basically unpredictable.

That is why there is subtle mistake in trying to design software to be adaptable. It is a contradiction. Design is using knowledge to make something, but the whole point about the kind of change we are facing here is that it is basically unpredictable. You cannot design for the future, because you cannot design for what you do not know. You just have to adapt when it arrives.

Or something.

Really great article with a good insight into daily life. I like the way he talks about basic physical maintenance/updates and applies the same concepts to software/hardware updates. Cleaning the gutters is no fun, but I have to do it every week in the spring and fall. The moral, I think, is to accept or even embrace change and learn to deal with it.