Embracing “Old” Tech

Personally, I've set 10 years for myself as a reasonable timespan, and I round up or down the version number to where it makes sense in terms of larger changes that have happened throughout the version history of the respective piece of software.

There's a thought that Nassim Nicholas Taleb mentions in one of his books that I've frequently used as a mental model ever since coming across it: For a book that has continuously been read for the last 100 years, you can expect it will continue to be read for the next 100 years. For a book that has only come out last year and been continuously read since then, you should have an expectation that one year from now, people will stop reading it.

10 years is a number I've arrived at by experimentation, thinking about version histories of various bits of software I build upon. For example, for Python this takes me back to version 3.4, before type decorators and many other things hit the scene that I disapprove of anyway. So now, I test all my code with both version 3.4 and the newest version (3.11). I won't use language features from 3.11 that weren't already there in 3.4, and I won't use code in 3.4 that breaks or throws deprecation warnings in 3.11. I also apply this test to dependencies, seeing what happens if I try to get the newest version of some Python library running on version 3.4 of the interpreter.

This means, my code is engineered in such a way that it could have been in continuous operation for the last 10 years, while running continuous updates on what's underneath it. And this gives me a reasonable expectation that my code will require only minimal code changes over the next 10 years to keep up with whatever might arise.

With the python interpreter itself, it's remarkably easy to do that, and I feel it doesn't limit me in my own coding in any meaningful way. With other bits of software, including many python libraries that one might depend on, it would be absolutely unworkable. In such a case, I take that as a clear signal not to use the software/dependency at all.

This is a lot of work, but also a good forcing function that prevents me from becoming a dependency hog myself. It's also useful research, because I get to develop an understanding of what time does to a piece of software, i.e. what causes breakage through time versus what causes stability through time, because I see the breakage in other bits of software through the time axis that I simulate into the past. And this way, I can avoid those mistakes when designing my own software.

> The point is, the things we use to build applications are in a constant state of evolution and change.

Evolution and change are great!

The article misses a deeper issue though.

There is tech that evolves with breakage (PHP, large parts of the JS ecosystem etc.) and tech that evolves with compatible change (Go, Java, Clojure etc.)

There shouldn’t be anything wrong with starting on v(N-1). But there is something fundamentally wrong if vN breaks you.

Programmers get anxious about that for very good reasons. We already have enough work to do! Breaking changes looming over our heads is not something we like having to worry about.

I don’t know whether Next13 will or will not break Next12 code. But that’s besides the general point.

Don’t embrace “old” tech! Embrace _stable_ tech.

Everyone working for big corporations is going "Just a few versions behind? Lucky you!" now.

Hey, Kernel version 3 is not that old.