25 May 2016, 19:12

DevOps: Centered vs Bounded Community

And now for some navel gazing…

What makes DevOps DevOps?

I’m late to the discussion. There are some many different takes on what DevOps is, and defining it has been compared to blind men trying to describe an elephant (the image is from earlier, but I can’t find an earlier reference to it).

Most of the descriptions seem to be along the lines of “DevOps is a role that does X” or “if you do X, you’re doing DevOps.” It’s been about defining the boundary of what DevOps is and what it is not.

[Dan North]() had a great talk at Craft Conf. The overall talk is on embracing uncertainty but there’s a section where he talks about two classifications of communities:

  1. Centered communities are ones where there are principles which are aimed for. One’s involvement in the community is measured by trying to move towards the principles or away from them.*
  2. Bounded communities are ones where there are markers which indicate the edges of the community. One’s involvement in the community is measured by being inside the markers or outside of them.

This got me wondering. As I’ve said, most of the discussions I’ve seen talk about DevOps in a Bounded way. Does it make sense to talk about it in a Centered way? If we consider it from a Centered way, that means there’s a principle or multiple principles that we try to move towards. Those would include:

  • Automation: Methods as well as testing
  • Breaking down the silos: Understanding other roles and working together
  • Improvement: Looking for ways to learn and get better.

There’s more principles to include and depending on the discussion some principles or priorities for principles conflict with others, but I’m looking at the meta-discussion so am going to hand-wave on enumerating here.

There’s a kicker: principles can be phrased as boundaries. You can focus on “breaking down silos” or you can have a situation which has no silos. The former shows the striving towards that; the latter is a state (“is”). So, it may be hard to pick out, or this may all be an issue of the language we choose to us.

Let’s not forget the appeal of bounded. Practically bounded discussions provide more concrete items which people can try to learn and mimic (cargo cult maybe?). And Bounded discussions are more likely to create groups which will be incentivized to spread it (see Dan’s comments about the Agile communities and the Formal Processes which came out which could be sold). Centered discussions are more vague and can lead to an identity crisis.

Despite all of that, what I really like about the Centered way because it is a bit more inclusive. The bounded descriptions seem to create more of a “us vs them” situation and has lots of thems. This seems is counter to the “Breaking down silos” aspect.

I think that that’s a way we should be moving towards - at least, for my version of DevOps. I’m hoping that that is moving in the same direction as many others’ versions of DevOps. Maybe that’ll be enough for now…

12 Jul 2014, 23:44

OSCON 2014 - Full Stack Development

In other news, I’m giving a tutorial on the Go language at OSCON. This is a big one for me so hoping it goes well.

I'm Speaking at OSCON 2014

As part of the lead up to it, they sent a call out to the speakers asking us to comment on “full-stack development.” This was supposed to be submitted as a video, but I didn’t get to it in time. It was open ended, so not sure if it was supposed to be meaning or impact. So, here’s some quick thoughts on it.

Fundamentally, being able to address the full stack is about autonomy. Much has been done to show that people a driven by having feelings of autonomy, mastery, and purpose (see Daniel Pink). The idea is that if we feel like we are able to own the work, we are more motivated to complete it. I think we can all think of personal projects which we’ve been caught up in and put in the extra effort on them. Part (yeah, only part) of what drives us is that we get to set the terms of the project - how it’s conceived, how it’s developed, and how it’s delivered.

In many organizations, much of this work has been given to specialized functional units so it’s harder to have ownership in those sections. Thinking about he full stack let’s us insert ourselves into those parts of the project. Basically, being a full stack developer gives you more changes to get that autonomy back.