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.

Comments

Popular posts from this blog

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…

When Is Software Done?

I have some very exciting news.  A piece of software I've been working on for over 2 years is released to the general public!  This is a little exciting if it were software I'd been working on for some big company.  It's very exciting because it's software I have been working on for my company.  That's right!  My company is ready to start selling software and start making money!

I'm not gonna use this blog post to talk about my company and what it does.  You can read about that in our press release.  Instead, I'm going to talk about the software industry and the concept of done.  Because, as with everything, it's more complicated than it seems.

Software is never really done
Actually that's a misnomer.  Software can really be done.  But done is sort of a quantum state--there and not there at the same time.  First and foremost, anyone can understand that software that works is complete.  If the software's purpose is to process a credit card, if th…

How to identify a skilled programmer during an interview

How does one identify a skilled programmer?  No company that has interviewed me could tell the difference between myself and other programmers they'd interview.  The interview process is truly a game of luck in this industry--on both sides.  Both the programmer and the company are basing their actions entirely on luck.

Companies have come up with numerous methods to attempt to discern a good programmer from a bad one.  The best tricks they have include a series of math problems, algorithms, problem solving technique tests, and even obscure programming questions, some without definitive answers.  As an example: Is there an authoritative source of information on the core principles that define object oriented programming?  I've heard everywhere from 3 to 7.  In a field of research about a synthetic concept, an authoritative answer is almost impossible to obtain.

Programmers were then forced to study to the interview.  Careercup is one of my favorite sites for this.  This almost …