[ Content | View menu ]

What is a DevOp?

Mark Mzyk June 22, 2013

What is a grit, anyways?

Vinny, My Cousin Vinny

More and more there are job posting that are looking for a DevOps engineer. In response to this a series of blog posts have appeared bemoaning the fact that there should be no such thing as a DevOps engineer because DevOps is a cultural movement. It’s a movement about cooperation between development, operations, and the rest of the business. So how did seemingly smart people decide they need to hire a DevOps engineer?

When the agile movement started there wasn’t a corresponding spike in job postings looking for agile engineers. It was understood that agile was a cultural movement. It wasn’t until later that systems came along that tried to codify practices that good agile shops did (Scrum, etc) and then we started seeing job postings for scrum masters and other related positions. Perhaps it was clear that the agile movement was a cultural movement because it started with a manifesto. DevOps has no corresponding manifesto.

It’s worthwhile to consider where DevOps started. While DevOps doesn’t have a single genesis, it seems widely agreed upon that it really came to light with John Allspaw’s and Paul Hammond’s 2009 presentation on developer and operations cooperation. The presentation is clearly a cultural presentation, at least when viewed in hindsight. While I wasn’t paying attention to the presentation when it came out, based on what I’ve heard the main take away was Flickr doing ten deploys a day. At the time that was amazing. And while it was a culture that enabled this, the was also a lot of technical practices in the presentation. Perhaps highlighting ten deploys a day in the title was a mistake. It made it easy to focus on the technical and miss how important the cultural aspect was.

Further confounding the problem is that good DevOp shops are most easily recognized by the tools and technical practices they follow. They use configuration management (Chef, Puppet, etc), they do continuous deployment, etc. While these tools are part of a larger culture they are the easiest thing to recognize about DevOps. Therefore, if you want to implement DevOps it’s easy to make the mistake of thinking that you need a DevOps engineer to implement these tools and miss the larger cultural shift that is also needed.

Going back to the comparison with the agile movement, when trying to find a good agile shop one is looking for the culture. Do they use short iterations, do they avoid heavy documentation unless necessary, etc. I’m not saying there isn’t plenty of argument over what makes a place agile, but we can agree that the argument is over cultural practices. Now look at DevOps. We say DevOps is a cultural movement, but then we look at the practices that define a good DevOps shop and we largely talk about the tools, software, and technical implementations that are used.

Is this a perfect break down? No. Certainly there is a conversation going on about the cultural side of DevOps. See Allspaw’s continued conversation around blameless post mortems, as well as Gene Kim’s book (along with co-authors Kevin Behr and George Spafford) The Phoenix Project which links DevOps to the work of Goldratt and shows how DevOps fits into the wider business culture. However, cultural change is hard. If given a choice between changing culture and changing some technical practices, it’s easier to change the technical practices.

Hence the rise of the DevOps engineer job posting. It’s a sign that the wider and more important cultural aspects of DevOps are being missed. It’s also a sign that those of us who are on the front lines of the DevOps movement are doing a poor job communicating it. We’ve muddled the message. Can we change this now? No, but neither should we try. Both the cultural and technical aspects of DevOps are important and we should be glad that businesses are trying to implement them, even if they don’t fully understand the entire picture. We can see from how the agile movement has developed that change like this is messy. As much as we as engineers would like it to be bug free, that simply isn’t going to happen.

What we can do is continue to preach the virtues of DevOps, both the cultural and the technical aspects of it, but we should highlight how the technical aspects fit within the larger culture. Highlight that while continuous delivery is good, it can’t reach it’s full potentially without the cooperation that DevOps advocates.

I am sure the day is coming when DevOps will get its first set of defined practices similar to how Scrum defined a set of practices for being agile. It’s inevitable, it will happen. Please write blog posts and bitch about it when it does. But also rejoice, because it will mean the flag has been raised and DevOps will have won the battle for minds, even if means the battle of how to implement it will continue. Then we can turn our attention to the next movement and start this same argument all over again, because culture never ends.

 


The Pragmatic Programmer Reread, Part 1

Mark Mzyk May 31, 2013

I’ve begun rereading The Pragmatic Programmer. It was originally recommended to me by someone at my first job out of college, which was six years ago. Now I’m in a position where I’m the more experienced programmer working with younger programmers. It’s good time to pick up the book again and see if what lessons I’ve forgotten from it and what I can pass on to others.

As I’m read it I’m taking notes, especially around each of the tips. Presented here are my notes, copy and pasted. There will be eight of these posts, as the book has eight major sections and that’s how I’m dividing my notes. Hopefully you find this useful as an abbreviated guide to what the book teaches. If you haven’t read the book, pick up a copy and read it, because no notes can do it full justice.

 

A Pragmatic Programmer is:

Early adopter/fast adapter – ties into Jack of all trades – try lots of new things

Inquisitive – try lots of new things, always learning – never know when you will need the knowledge

Critical Thinker

Realist

Jack of all trades (specialize when need to, but keep abreast of developments)

 

Tip 1: Care About Your Craft

Tip 2: Think! About Your Work

Tip 2 follows from Tip 1

Be a craftsman. You may be part of a larger team, but in your individual work you can leave your mark.

If one builder of a cathedral doesn’t give a damn about his bricks, won’t that stand out when you marvel at the otherwise amazing building?

(To expand on the analogy used in the book)

Learning and improving is a continuous process. You get better one small step at a time.

So too, we’re learning this about software. Small steps lead to large improvements (continuous delivery anyone?)

Always be aware of the big picture in which you work – it informs your work and what you do.

And the big picture changes in scope – it’s your team, your company, your country, the human race, the universe. All apply, but how often do we think of each of these?

 

Tip 3: Provide Options, Don’t Make Lame Excuses

Take responsibility for your work, which means admitting when you are wrong and providing ways to fix things.

Also remember: if the situation you’re in is impossible, you can step away and not take responsibility – but don’t act like you are going to take responsibility only to bail later.

 

Tip 4: Don’t Live With Broken Windows

Simple idea: take care of your code. If you inherit bad code, clean it up. Maybe you can’t right away, but start. Put up signs that you are, so it is clear someone cares.

Then others will care to.

See Tip 1.

 

Tip 5: Be a Catalyst for Change

Sometimes to make change, you have to go rogue, which can be as simple as hiding your larger intentions while getting a project rolling.

 

Tip 6: Remember the Big Picture

The big picture is why you do the work you do. It’s easy to get caught up in the code, but if you don’t put things in context that’s when you build the wrong thing,

or you miss how things are changing around you.

 

Tip 7: Make Quality a Requirements Issue

Let the user decide when a piece of software is good enough – not everything needs to be gold plated.

Corollary: Ship Early, Ship Often

 

Tip 8: Invest Regularly in Your Knowledge Portfolio

Straight forward: Keep learning.

 

Tip 9: Critically Analyze What You Read and Hear

Learning doesn’t help you much if you don’t think about it.

See Tip 2.

 

Tip 10: It’s Both What You Say and the Way You Say It

Effective communication and persuasion take work. You’ll need to practice it just like you would practice a new coding skill.

 

[Author’s Note: This post edited on June 11th to improve formatting for easier reading from the original posting]


Thought Leader

Mark Mzyk May 1, 2013

The term thought leader is being thrown around a lot lately, mostly in a derisive way, since it is over used. The Wikipedia definition, copied wholesale here, is this:

Thought leader is management terminology for a person or an entity that is recognized by peers for having progressive and innovative ideas. Typically thought leaders have proven themselves in the business, academic or political sphere through successful implementation of their ideas. Thought leaders often publish articles and blog posts on trends and topics influencing an industry or directed internal to an organization. Through effective communication and clarity of purpose, they effect change and are considered exemplary leaders.

That works as a definition, but I think it misses a crucial component of a thought leader. My definition would be this:

A thought leader is someone who takes disparate ideas and expresses them as a cogent whole. This doesn’t mean they necessarily have original ideas (although they often do), just that they are good at expressing and merging ideas into something new and useful.

Another part of being a thought leader is that you have to be visible. If no one knows of your ideas, then by definition you can’t be a thought leader.

You also can’t be a thought leader by calling yourself one. It’s a term bestowed on you by others. It should never show up on a business card.