2 ms·
Yup, it seems that this 'effect' is simply extrapolating from randomness and averages. Take any random thing and random time (with zero knowledge of actual lif
by toss1 4y ago
Yup, it seems that this 'effect' is simply extrapolating from randomness and averages.
Take any random thing and random time (with zero knowledge of actual lifespan), and on average, you are in the middle of it's lifespan. Therefore, if Thing-A has existed for 28 years, it is likely to last for another 28, if Thing-B has existed for 6 years, it's likely to exist for another 6, and so on.
It may be somewhat informative for comparisons but not in real life.
You are hiking away from a disaster with all your possessions and life's savings in your backpack, and are now at a muddy riverbank needing to cross. You ask me how deep the river is and I tell you the average depth is 6 inches. That sounds great, but I have most definitely NOT told you that you'll be able to get across without finding a deep spot and having to drop your backpack to survive.
Using this effect to make judgements about product lifetime is similarly uninformative. It is a hint leading to only a possible inference, not data leading to a valid prediction.
- syntheweave 4y agoWith respect to software objects, the most likely reasons for their life to end are: 1. Not sufficiently useful relative to involved costs for most applications(data formats, configuration maintenance, etc.) 2. Disrupted by something that is "10x better" for the purpose(e.g. using a spreadsheet instead of a text editor for 2D, cell-oriented data) 3. Outside forces invading the ecosystem and obsoleting dependencies(new OS, hardware, etc.) So what the Lindy effect describes in long-lived software is just the software that is relatively cheap to keep around, is hard to greatly surpass and resists invasion - which describes a lot of "worse-is-better" software, where the UX kinda sucks, and it's actually a bit too unstructured for any particular application, but not enough of these things that anyone cares to address it in the relevant professional scenarios where it comes up: instead the user just girds themselves to fight it into submission because they can spend six hours fighting it and one week debugging it or two weeks making a Right Thing that is much less compatible.