This is an extremely odd way of making technology choices - especially the arbitrary 5 year limit that means having to use an older version of a framework.
> There were many quality of life improvements between Elixir 1.7 of 2018 and the Elixir 1.15 of today, but for most of our application coding these would make little to no difference.
I've read McKinley's "Choose Boring Technologies" essay a few times. It is okay. I have no big objections to it, though I think the "innovation token" metaphor is oversimplified.
Yet every time I encounter it in the wild, it's always used to justify the most backwards technical decisions. They have included
- using Ember.js in 2018
- waiting 18 months before installing security patches
- continuing with Java 7 back in 2021
- an engineer who wanted to build his web service in C with CGI in 2019
It's like flypaper for people who can't process change
5 comments
[ 3.2 ms ] story [ 235 ms ] thread> There were many quality of life improvements between Elixir 1.7 of 2018 and the Elixir 1.15 of today, but for most of our application coding these would make little to no difference.
There were also a few security fixes.
The 5 year limit is regarding not having major/breaking changes.
Yet every time I encounter it in the wild, it's always used to justify the most backwards technical decisions. They have included
- using Ember.js in 2018
- waiting 18 months before installing security patches
- continuing with Java 7 back in 2021
- an engineer who wanted to build his web service in C with CGI in 2019
It's like flypaper for people who can't process change