This shows a profound lack of understanding into why operations does things the way it does. Our primary task, above all else, is to make sure that the infrastructure and thus the application keep running. We often take the blame if a developer's app is deployed into prod, runs for 3 days, and then dies. When their app dies in prod, I'm the first person to get paged (and there's a really good chance your developers don't even carry a pager).
> You use hand-overs, procedures & documentation requirements to slow us down.
Which we do not to irritate you, but because we need to support your application in production. I need to know if/when/how your application needs to be shut down, because I've shut down things like Tomcat before and gotten yelled at because they've done something weird that prevents a normal shutdown from being safe.
> You hide behind bureaucracy and use ISO standardization as an excuse.
Developers often don't realize this, but there's a lot more communication that needs to happen on our side to make a change than yours. Every change I want to make needs to be verified with half of infrastructure to make sure it won't impact their processes. Security has enabled an IDS that then broke applications by screwing with TCP negotiation on database connections. We've had SMB authentication be broken by reverse proxies. Everything we do can impact someone else, and can impact all of the however many apps we manage.
> You make the infrastructure overly complex, using SPOF as an argument.
This is an almost scary comment. The infrastructure isn't overly complex, it's just as complex as it needs to be to support that ancient app from 1995 that none of the developers want to take ownership of that has no HA or clustering built in, but is still a required service for 75% of the business. That HA isn't there for that fancy new app with clustering built in that was designed to not require hardware redundancy.
You get paid to write software so the business can work more efficiently, I get paid to make sure that your software stays up so the business can use it.
> We do not like meetings, documentation or other waste in this process
I should add:
"We like to try a fancy languages no one else is familiar with, and when we leave the company we make sure we leave a nice piece of shitty, completely undocumented code running in the infra, which has some bugs that never had time to address and which has been packaged manually and links to a very special library that was downloaded in a zip file attached to some blog post."
That's probably the most short-sighted list of excuses I've ever read.
Recently I had an interview with a developer candidate who questioned or derided every design decision I made as CTO at our company, because he had no concept of the realities involved with those decisions. What appears illogical or a waste of time from a single point of view is actually perfectly logical and will save a ton of time later when you take the overall view.
The constant discounting of decades of experience is particularly grating. One of the reasons I did X was because I dealt with Y twenty years ago, and I'd rather not deal with it again.
I wouldn't want to work with the author of the manifesto.
I think the answer to a better Dev and Operations relationship is to involve people who can deal with any types of situations without being adversarial.
Yes, you can scrap operations sometimes, but sometimes you can scrap development and use off the shelf or 3rd party software as much as you possibly can.
> You use hand-overs, procedures & documentation requirements to slow us down.
Which we do not to irritate you, but because we need to support your application in production. I need to know if/when/how your application needs to be shut down, because I've shut down things like Tomcat before and gotten yelled at because they've done something weird that prevents a normal shutdown from being safe.
> You hide behind bureaucracy and use ISO standardization as an excuse.
Developers often don't realize this, but there's a lot more communication that needs to happen on our side to make a change than yours. Every change I want to make needs to be verified with half of infrastructure to make sure it won't impact their processes. Security has enabled an IDS that then broke applications by screwing with TCP negotiation on database connections. We've had SMB authentication be broken by reverse proxies. Everything we do can impact someone else, and can impact all of the however many apps we manage.
> You make the infrastructure overly complex, using SPOF as an argument.
This is an almost scary comment. The infrastructure isn't overly complex, it's just as complex as it needs to be to support that ancient app from 1995 that none of the developers want to take ownership of that has no HA or clustering built in, but is still a required service for 75% of the business. That HA isn't there for that fancy new app with clustering built in that was designed to not require hardware redundancy.
You get paid to write software so the business can work more efficiently, I get paid to make sure that your software stays up so the business can use it.