2 ms·

Here is one way, I use the Lindy effect as a mental model: When picking a tech stack for a software investment and you want a reasonable expectation that it wi

Here is one way, I use the Lindy effect as a mental model: When picking a tech stack for a software investment and you want a reasonable expectation that it will still be actively maintained 10 years from now, you need to go back in time by 10 years. I’ve found this 10 years time horizon a useful one to work with, based on 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. 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, paying close attention to what happens if I try to get the newest version of some Python library running on version 3.4 of the interpreter or a 10-year-old version of the library on version 3.11 of the interpreter. This means my code is engineered so 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. I feel it doesn’t limit my 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 dependency at all. This is a lot of work, but also a good forcing function that prevents me from becoming a dependency hog myself.

emblaegh 3y ago
Sounds like there would be barely any up to date dependency that you could use, which in some cases could have known security issues, no?
- stakhanov 3y ago
  To clarify: I still run the latest version of all the packages I depend on. For example, the newest version of SSL that you can still use with Python 3.4 has known issues. But I don't use that in production. I use Python 3.11 with an up-to-date SSL, but the code that I've written myself is code that I've also tested on Python 3.4 with outdated SSL. So the subset of features I use is a set of features considered by Python and SSL maintainers as so essential that they've maintained compatibility around them for ten years, and are therefore likely to maintain compatibility around for another ten years. -- Whether that's true no one can know, but applying the Lindy effect mental model would imply that this would be a useful way to think about it. The packages I get to use after applying the above filter are a minority, but, surprisingly, it's not "barely any" either. If you decide to live like this, you'll have less eyecandy in your life and less capability to capitalize on all the latest hotness all the time. But you'll get the job done, pretty much regardless of what the job might be. Your dependency hog colleagues will call you a dinosaur for your choice of tech stack. But when security vulnerabilities happen then, more often than not, there won't be any action needed on your part because, more often than not, you'll discover that you don't depend on the thing that has the vulnerability in the first place. You'll be home for dinner, while those same colleagues try to patch their dependencies, watch their software break, and try to work their way out of dependency hell (presumably by introducing more dependencies).
  - emblaegh 3y ago
    Ah, ok, that makes way more sense.

emblaegh 3y ago

Sounds like there would be barely any up to date dependency that you could use, which in some cases could have known security issues, no?

stakhanov 3y ago
To clarify: I still run the latest version of all the packages I depend on. For example, the newest version of SSL that you can still use with Python 3.4 has known issues. But I don't use that in production. I use Python 3.11 with an up-to-date SSL, but the code that I've written myself is code that I've also tested on Python 3.4 with outdated SSL. So the subset of features I use is a set of features considered by Python and SSL maintainers as so essential that they've maintained compatibility around them for ten years, and are therefore likely to maintain compatibility around for another ten years. -- Whether that's true no one can know, but applying the Lindy effect mental model would imply that this would be a useful way to think about it. The packages I get to use after applying the above filter are a minority, but, surprisingly, it's not "barely any" either. If you decide to live like this, you'll have less eyecandy in your life and less capability to capitalize on all the latest hotness all the time. But you'll get the job done, pretty much regardless of what the job might be. Your dependency hog colleagues will call you a dinosaur for your choice of tech stack. But when security vulnerabilities happen then, more often than not, there won't be any action needed on your part because, more often than not, you'll discover that you don't depend on the thing that has the vulnerability in the first place. You'll be home for dinner, while those same colleagues try to patch their dependencies, watch their software break, and try to work their way out of dependency hell (presumably by introducing more dependencies).
- emblaegh 3y ago
  Ah, ok, that makes way more sense.