I find this current trend to hate DevOps to be childish. DevOps was a response to a very real problem of “throw it over the wall,” where the Dev team would build it and the Ops team had to figure out how to make it run, usually without any documentation. The change to having the Dev team responsible for deploying and running the product (and responding to the on-call they cause) creates a forcing function for the team itself to improve quality and deployment efficiency.
Your analogy makes literally no sense because what you’re trying to achieve in a courtroom is not the same thing you’re trying to achieve in a software engineering organisation.
Sure it is, you explicitly want features and stability.
Having 10,000 production ready features with 97% uptime and no backups is not desirable. So what has happened instead is a burnout epidemic among software developers who desperately attempt to relearn operations- or a rebranding of sysadmins to be “devops engineers”.
The very real problem you cite still happens in the latter case.
I have almost never seen an embedded sysadmin (as the 10+deploys a day talk suggests; and most people are talking about mentality-wise when discussing devops).
Others think that developers can do the job, but it’s easier than you think to be paralysed mentally by holding too many opposing views at once, which is why those kinds of things are short lived or the developers become the new operations staff purely.
I think it makes more sense to have someone specializing in OPs and someone specializing in feature delivery. They are totally different skillsets. If you have both great but just demanding regular feature devs to also figure out all the network plumbing and deployments is just regular old business folks squeezing blood out of rocks.
It's not about forcing every Dev to learn every aspect of Ops work. It's about ensuring the team that builds the feature manages its delivery end-to-end, including dev, test, deployment, failure response.
The reason for this is, as I pointed out, because the organisations that created a hard split had much worse outcomes for customers and themselves. This split might have been necessary in the past, due to the vast gap in skill-sets and operating environments.
However, most orgs now will create a different split where a team manages the underlying infrastructure and tooling (to varying levels, depending on the specialisation required), but developers are responsible for ensuring their code Runs on Prod (tm). This does not mean developers are regularly fitting their own server racks and hand-wiring their networking infrastructure. It means, for the third time, developers own the delivery of their code to prod, end-to-end.
I believe we now have enough info to quantify the tradeoffs.
Dev is the sperm, Ops is the egg (or vice versa).
And it takes time for the sperm to talk to the egg. The sperm must travel. He types in Slack "Hello <Name>, I have simple trick to save money for bewba service.". The egg must travel, type in Slack, "I can't find bewba service in our catalog but I can't say that out loud".
Through time and effort, the sperm and egg finally connect, and the bewba service's money guzzling is shaved.
When the scenario is right, the travel time is not worth it. We kill of one of the sperm and egg, and accept the risks. The killed sperm-or-egg leaves the circle, and everybody in the circle is satisfied.
Your analogy makes literally no sense because what you’re trying to achieve in a courtroom is not the same thing you’re trying to achieve in a software engineering organisation.