Skip to main content

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.


Popular posts from this blog

Teams and Complexity

Let's pretend you're a car mechanic (I don't know, maybe you are).  But you don't work at some shop in town, you work at a bigtime auto-maker onsite at the factory.  You help build cars from scratch.  You work with a lot of other car mechanics, and various engineers of different levels.  If we were looking at the 1910s, you might be working for Henry Ford on one of the first ever assembly lines.  Either way, you have a specific part of the car you're responsible for.  Your skills probably extend beyond that, and you might work on a different part of the car each day as your manager moves you around to keep the factory efficient.

One of your coworkers, Bob, is a superb engineer.  He is very good at building cars, far better than you, and he does it faster than everyone else.  Your boss really likes him.  You often get stuck after him in the assembly line, so you know exactly what sorts of things he does.  He's not sloppy, but he likes to do things his way.  He w…

Managing Programmers

Working with other programmers is tricky.  That said, it's nothing compared to the job of managing programmers.  One of my favorite quotes about Perl is that (paraphrased) "a Perl developer is like a rockstar.  Now imaging having a bunch of rockstars in one room together and you will understand why you don't want an entire team of Perl developers."  It's not about Perl here though. What's important to understand is that any developer worth his salt is going to be like a rockstar.  And yes, there are a lot of professional developers out there who aren't worth their salt, but that's for another post another day.  Rockstar may not be the right term here, but think of it this way.  These guys are smart.  They may not be geniuses, but there's going to be things that they know that you don't and probably never will.

I've seen it more than once and it's not going to make some Product Managers happy, but I'm going to state a fact, an eleph…

Managing Developers is HARD

I've been a software dev for a long time.  I've also been running my own software company for a few years now.  This is important information because of why I do these things.  I am a sofware developer because I love learning.  I slack off when doing a job that bores me, and software development always has something new to experience which keeps me excited and interested.  Why start a software company then?  That puts me in the role of manager rather than developer.  The truth is simple.  I've worked for a lot of companies, and I don't see any of them doing a great job of managing their software development.  That's not to say none of them have done a good job, but no one out there seems to be doing a great job.

How are they different?
A lot of companies get this part right.  Software developers are different from other employees.  The distinction is important in the same way it's important to acknowledge that an insurance agent is different from a construction…