Some believe we eliminated the need for this school of thought through the DevOps revolution of the 2010s. Dev and Ops became one, married in the form of one man with one job in one company in one world. That was when history and current became one, and the many problems became zero.
With that mentality, why have lawyers for a prosecution and defence? Just have a judge decide.. right?
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.
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.
You’re the only one making this strawman argument, here.
> the 10+deploys a day talk
Most teams aren’t doing this outside of a rush to wrap up a feature before a major announcement. It’s not a daily occurrence.
> but it’s easier than you think to be paralysed mentally by holding too many opposing views at once
What on Earth are you talking about?
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.
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.
...yes? That's known as the contrast between an "adversarial" and an "inquisitorial" system. The inquisitorial system is more intuitive and more widespread.
A quirk of the adversarial system as practiced by the USA is that judges have no responsibility to make correct rulings. If the law is very clear on some point, and neither party makes that observation to the court, the court is not just not required to know the law, they're not supposed to use that knowledge even if they have it.
I don't really find it surprising that most people think the job of the court should be determining "who's right?" as opposed to "who gave a better technical performance in arguing their case?".
We see this a lot with daring "idea people" types seemingly plowing forward while the actual work is done by everyone around them, curating the firehose of random ideas and making the good ones into reality.
On an org level it doesn't matter as long as employees stay, but that usually doesn't last long.