Comment by adolph
2 years ago
> where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion
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.
If you choose the right frameworks which have sufficient momentum to last you say 10 years, you don't have to put yourself in the dilemma.
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.
> Besides the infamous Javascript framework churn
reactjs came out in 2013, so it meets the 10y metric, but it has some internal churn, such as classes, hooks, etc
“If you choose the right frameworks” is a big if. Even within a framework, there is versioning and dependency management to account for. Consider the log4j vulnerability. The cost and risk of patching something untouched for 10 years is higher than something touched more recently.
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?
https://luca-dellanna.com/what-is-ergodicity/
Hey, if the 1990s DEC hardware still works, and it'd be more expensive to change it...
There are PDP-11s running nuclear plants today with support contracts to keep them running until 2050.
PDP-11s.
That is a great example. By not taking account of risk on the front end by embracing change, the system gets progressively more expensive to maintain (extended support contracts) and the risk of eventual inevitable change grows higher. Further, the system becomes progressively less valuable compared with newer systems.
> becomes progressively less valuable compared with newer systems.
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.