I cannot speak to the modern Web development, as I can only have a glimpse over the shoulder of someone else doing that every once in a while. But, I see a sim

I cannot speak to the modern Web development, as I can only have a glimpse over the shoulder of someone else doing that every once in a while. But, I see a similar problem with development environment configuration and management. It's common to have multiple configuration files for multiple utilities that are supposed to do something in development environment: run tests, lint source code, spawn a mock-up of the system being developed, perhaps some VCS automation and often all sorts of integrations with other tools used in the project. Projects become cluttered with various "dot-files" with various configuration formats, and because those tools need to cooperate somehow, you also see bits of configuration for one tool embedded (while escaped) in configuration for another tool, and sometimes even multiple layers of escaping. There are usually straight-forward alternatives that simplify the process, make it more uniform. My explanation for why those alternatives aren't used is vanity. Users of projects with unwieldy configurations pride themselves on knowing and using a bunch of (unnecessary) tools, they like to appear savvy to their peers by discussing advantages of and new developments in these tools. And because the explanation is so simple and so unflattering, few will dare to acknowledge it. It's also usually the case that one would need at least some years of experience to accumulate all the useless knowledge of development infrastructure tools, and so these "opinions" about tools will often come from more senior programmers in the group, often driving the junior programmers to unquestionably accept the unnecessary complexity of their environments as status quo and come up with all sorts of rationalizations for why it's normal to have this many cross-referencing configuration files and various infra tools. I've lost count of arguments I've lost when suggesting a simpler automation solution which didn't use (an unnecessary) tool. Here's just one example: A project aims to deploy a Python application with external dependencies (packages) in containers. Using pip to install stuff in containers was problematic because it took forever (due to solving dependency constraints, downloading from PyPI, installing a bunch of stuff irrelevant to the target application s.a. scripts for dependency packages, or tests etc. finally, poor network utilization). I suggested having a CI job which pulled vetted versions of packages on-demand, then have it strip those packages of unneeded cruft, put them in a tarball and use that for building containers. You had to watch the guy who was a level above me in work hierarchy and was somehow responsible for CI get red in the face and start making saliva bubbles as he was getting ready to destroy and ridicule my "insane" idea... all because it didn't use pip.