The churn gets very tiring at one point and you begin to suspect that the people who impose it on you actually have no clue what they're doing and are taking the easy way out because they want to clock out for the week. Which I do understand but pretending that it's for the good of everyone is obviously bogus.
IMO all you scientist folks should work closely with a few programmers and sysadmins and have them author you tools to bring up and down various environments. It's easy and it's much more churn-proof than what we currently do.
I am still in the process of authoring a script to bring up my dev environment everywhere I go, I need to iron out a few kinks in the initial bootstrap (as in, OS and Linux-distro specific ways to install several critically important tools before installing everything else) and I'll just provision a few laptops at home and a VM in the cloud and be done with it.
It's annoying but ultimately a worth investment. Look into it and ask your dev friends.
The problem is most people aren’t happy with stuff being the same way forever. They want new things and new updates, and that requires changes which in turn creates maintenance.
Software maintenance is less comparable to a single academic paper than it is to the entire field of academia. Sure Freud's papers are all exactly as they were when he published, but if you want to be in the field of psychology you’re going to have a bad time if that’s the most recent version of your academic “software stack”
> The problem is most people aren’t happy with stuff being the same way forever. They want new things and new updates
I agree, from what I can tell. Personally I'd prefer that software UI not change nearly as often as it does, but I concede that I'm apparently in the minority.
I'm generally writing web apps, requiring me to keep up with a stream of security updates just to stay online: browsers deprecated TLS 1.0 and 1.1 [1], browsers require TLS certificates to be renewed ~annually, languages only fix security vulnerabilities for the last few releases, etc. Even linux kernels are getting shorter support going forward. [3]
[1] https://security.stackexchange.com/questions/237688/when-wil...
[2] https://www.digicert.com/faq/public-trust-and-certificates/h...
[3] https://www.linuxjournal.com/content/linux-kernel-reduction-...
If the software stack is reproducible, then you decouple that to the environment and hence upgrading the OS shouldn’t break it.
(That said it is very difficult to be 100% reproducible, eg your hardware can change from x64 to arm64… that’s why people are suggesting docker. I don’t like docker in the sense that it is a lazy approach to make things reproducible. But the guarantee there is very high.)
For science, not really - what use is the GP's partner's data if it cannot be reproduced?
I know, I know ... scientists go ahead and publish non-reproducible studies anyway, but it's widely acknowledged as bad science.
For scientists, containers seem to be a much more important than just about anything else, especially for publications, because reproducibility is at the core of the work being done.
> In the software world, it seems to be universally accepted that everything will change, all of the time, and one needs to keep up. If your dependencies break, it's your responsibility to update those too. Hence software "maintenance", which requires a lot of effort.
> In my world, maintenance is not a concern. If I write a paper, then once it's done it's done. Academic papers, too, have dependencies: "By Theorem 3.4 of Jones and Smith [14], we can conclude that every quasiregular foozle is blahblah, and therefore..." You don't have to worry that Jones and Smith are going to rewrite their paper, change their definition of "quasiregular", or renumber everything.
> Different cultures. Personally, I prefer my own.
Those are the problem with SW developers: they don't have a concept of a finished product and (some of them) never finish the product.
Supremely unrealistic expectation anywhere else
In the software world, it seems to be universally accepted that everything will change, all of the time, and one needs to keep up. If your dependencies break, it's your responsibility to update those too. Hence software "maintenance", which requires a lot of effort.
In my world, maintenance is not a concern. If I write a paper, then once it's done it's done. Academic papers, too, have dependencies: "By Theorem 3.4 of Jones and Smith [14], we can conclude that every quasiregular foozle is blahblah, and therefore..." You don't have to worry that Jones and Smith are going to rewrite their paper, change their definition of "quasiregular", or renumber everything.
Different cultures. Personally, I prefer my own.