3 ms·
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
by stakhanov 4y ago
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.
- analyzethis 4y agoTaleb calls it the Lindy effect. https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect
- krackers 4y agoThere's a certain comfort in using a language that's "done" and is not going to change from beneath your feet. It's also one of the reasons why I strangely like python2. Compared to python3 which has a new release every year (and requires you to update all libraries that now are only compatible with the new version, causing a lot of churn for no reason), python2 still continues chugging along, and you know that people still targeting it value stability over breaking change.