There’s a school of thought in management where you get your team to lean into their strengths and find ways to mitigate their weaknesses, rather than spend much time on them. The idea is, if you’re a person who moves quickly vs going super deep on every possible use case, you’ll always be shit at going super deep (I know I am), so you’re better off getting even faster and pairing with a deep investigator to cover your blind spot. And vice versa, of course.
This could work fine if the pair is acknowledged as such. In most orgs one side of the pair will be just be seen as a replaceable counter-weight while the other side gets the praise and promotions.
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.
This may be one reason employees have different titles. The other reason I can think of is why owners aren't usually called employees.
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.
Dev and Ops are natural enemies because they are focusing in pulling in opposite directions, a fact thats repeated ad infinitum in the course material surrounding devops - yet people still hold the belief that one person can fiercely hold two diametrically opposed positions at once and succeed.
With that mentality, why have lawyers for a prosecution and defence? Just have a judge decide.. right?
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.
> With that mentality, why have lawyers for a prosecution and defence? Just have a judge decide.. right?
...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?".
