Dev v Ops

When we think about programming, we think about source code. Scenes from the matrix come to mind, with streaming source code everywhere. We think about files, and databases. We think about architecture diagrams and class structures. We think about good practices and code patterns.

We rarely think about deployment

As a developer who has routinely deployed his own applications I know what it means to be in the Operations role. I know that sometimes hardware breaks. Sometimes time-zones are incorrect. Sometimes processors get overloaded. Sometimes (nearly always) your test environment isn’t the same as your production environment. Sometimes permissions break (ACL) or your middleware goes down (IIS) or your infrastructure has to be moved to the cloud (AWS) on the weekend.

It’s crazy being an Ops guy. I don’t envy the challenges they face. In fact, I hold their skill in high regard. But that’s not something I see a lot of developers do. In fact, more often than not, due to their opposing concerns, devs and ops tend to butt heads and scream at each other. What’s scary though, is that the ops guys are usually right, and rarely the winner of said argument.

Ops have legitimate concerns

I went a little extreme there. What I’m talking about was well articulated just this week by Jeff Atwood. Now don’t be surprised by that link. It’s not about Ops. It’s about testing. But here’s the part that really struck the point home.

The machine that a program runs on will always be in the GMT time zone.

Ok, that’s not true. But at least the time zone in which a program has to run will never change.

Well, surely there will never be a change to the time zone in which a program has to run in production.

The system clock will always be set to the correct local time.

The system clock will always be set to a time that is not wildly different from the correct local time.

Think about how that’s just a few of the things that Ops get into it with developers over. Is it the Ops guy’s responsibility to provide you with a server that does everything you expect? Sure. Is it his fault if you never tell him everything you expect? Certainly not. More than that, the Ops guys job is to create an environment that’s as reliable as it can be. That does not mean it will never go down. But many devs never consider the possibility of the environment collapsing while their code is executing.

Devs want control

Devs have to manage many details in the code. Sometimes they are controlling every thread. Sometimes they’re running hundreds of thousands of database queries every second. Sometimes they’re pumping files to S3 in the terabytes in quantity. It’s insane the stuff we have to do. The tendency is to want to do it your way.

It gets crazy though. I’ve literally heard devs joke about 200+ gigabytes of RAM on VMs and go “meh, throw more RAM at it”. To an extent, our time is valuable and there needs to be an effort to limit the extra labor to enhance our code for optimization, but the other side of that is that there’s usually many less guys in Ops than in Dev.

Code that lasts

When I code, I have to remind myself of this little fact: If my code works well, there’s a good chance that it could be sitting for 10 years untouched. People don’t throw out things that work well. I mean, that exact thing was just in the news.

Think about that. Could your code run, untouched, without you tweaking it for 30 years? 20 years? 10 years? a year? 6 months? Most devs, heck most organizations will tell you that the answer is no to all of these questions. To be honest, half the ones who tell you that the answer is yes are lying.

DevOps Harmony

When I write code that lasts, I think differently about how I want it to work. I package my code up so it is a tiny ball that needs no attention. I create deployment code packages, something many Ops groups are still begging their developers to do to no avail. Why? Because it makes it easier on both of us. By having a simple process with very few steps for the Ops guy to follow, I ensure that my software doesn’t go down because of a deployment mistake. And the Ops guys love it because they know everything worked correctly.

More than that, handing deployments over to Ops lets me be lazy, and I love being lazy. I don’t have to sit up at 2am running the deployment script. The Ops guy does it. When I’m not allowed in production, they don’t call me, they call the Ops guy who has access.

I hope you agree, but if you don’t let me know why. Maybe I’m only seeing one side and I’d be interested to hear. Alternatively, if you do agree, be the change in your org and work toward harmony between yourself and the Ops team. It may well result in a better life.