And yes, 10 years is quite possible these days. Besides the infamous Javascript framework churn, things are moving quite a bit slower in recent years.
In part, this is due to the risks inherent to change have been spread out over 10 years instead of backloaded to the end.
Practicing mitigating risks by proactively taking them has value of its own. The parable of ergodic cakes shows this.[0] What % of cakes will fail if 10 people each bake one, versus one person baking 10 over time?
reactjs came out in 2013, so it meets the 10y metric, but it has some internal churn, such as classes, hooks, etc
There are PDP-11s running nuclear plants today with support contracts to keep them running until 2050.
PDP-11s.
Indeed, business people do not typically model depreciation curves for software as they should. That doesn't mean that the plant control system becomes less valuable (the value is tied to the operation of the plant, probably for the lifetime of the plant), but in many other situations it does mean that.
This sounds like an improvement over the opposite, a code base that is rarely touched and uses eol frameworks. Software is a living thing and if you don’t act as a ruthless gardener you wind up a museum curator with 1990s DEC hardware running in the 2010’s.
The right balance of staying current and not reinventing the wheel is not trivial.