https://journals.sagepub.com/doi/full/10.2466/09.02.10.CP.1....
… and sysadmins tend to be at the deep end of the spectrum
I find this "meh, you're just being stubborn" labeling is a bit dismissive. Especially when a lengthy technical comment about systemd is replied with the tone of "You just used to old ways eh? Time to freshen your knowledge, hehe".
Today's sysadmin dynamics doesn't allow one to stagnate with old knowledge either. Yes it's very useful, but not eternally. Instead it allows you to build knowledge faster.
Have you seen how many Python 2 packages there still are out there? How often do we see opinions on HN that amount to "C > *" whenever Rust, Go, Java, C++, etc. are in the submission? That's the exact same "resistance to change".
Change isn't a light switch. It doesn't go from 100% old to 100% new. Change is a long, slow, time consuming, and difficult process that requires extra effort at every stage in the process. There are several different stages:
1. Not knowing the new and being confused.
2. Identifying the new and having to develop special processes.
3. Accepting that the new is here to stay and translating or adapting the processes and procedures from the old, and spending effort to re-learn the same features in the new system to maintain business as usual.
4. Discovering all the new ways that the old process doesn't fit the new system or the new system isn't designed for your existing business processes, and fixing them one catastrophe at a time.
5. Running the old and new, simultaneously, for the lifespan of the systems that depend on them.
6. Having the new significantly overtake the old such that it's now unusual, and being frustrated that the old still exists.
7. Forgetting knowledge of the old via atrophy.
8. Encountering the old and being confused.
And that's when the new system proves itself to be better than the old.
Pretty much none. Can't say exactly how many, since http://py3readiness.org/ is dead.
* Infrastructure is often untestable. I've been bitten by the silliest changes in unexpected ways. We use IaC extensively, which makes things more organized and easier to operate, but still, testing stuff is insanely hard and time consuming, often impossible.
* Infrastructure is often thightly coupled. Many architectural decisions will come back to haunt you in the future, in very serious and unexpected ways.
* Infrastructure is often shared. Consequently, balancing requirements from different teams with different goals is very hard.
* Often, I have no skin in the game. I will not earn more money to implement changes that will benefit my peers, but my life will suck more if I do. Often, being a intransigent bureaucrat is the most rational path I can take.
* Often, devs have no skin in the game. They will earn more money if features get delivered, but won't have to deal with the long term operational and security consequences of the changes they ask for.
That was already repeated ad nauseam by others, but my best professional experiences were:
* The times I was responsible for software and infrastructure of a project.
* The times I was working in a small team, very close to devs and thinking about a single project.
This part just takes away from your argument,
>… and sysadmins tend to be at the deep end of the spectrum
Source?
We'll need a peer reviewed article to believe that.