
NoOps: Developer operations manifesto - kiyanwang
http://tqdev.com/2016-noops-developer-operations-manifesto
======
curryst
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.

------
alexandrerond
> 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."

Bonus points if it involves and old Gentoo box.

------
nasalgoat
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.

------
dimitar
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.

