A movement needs to move. Sure thing, right?
But why is it moving at all? Patrick Debois, with a somewhat sarcastic but truly charming undertone, puts it this way: “Where we are right now just sucks.” Well, that leaves vast room for interpretation. So, what exactly sucks and drives the DevOps movement to keep growing ever faster and ever louder?
First, let’s remind ourselves that the DevOps movement was started as an observation. The observation was that unspoken expectations in software development projects manifested themselves as bad habits – really bad habits. It was, and still is, habit to assume that a project will run late, and when the product is delivered, (if it is delivered at all) to assume that it will fall short of expectations. It is simply expected to under-perform.
DevOps is about breaking these bad habits. Furthermore, a deep fear of change usually emerges, which further exacerbates the problem when it comes to critical decisions – such as risky deployments, as just one of many examples. What is even worse, at least to us, is that the root cause has a name: Siloisation.
Divide et impera, or as we know it, divide and conquer.
A problem solving strategy, described first a few thousand years ago, says that big problems are best conquered by breaking them down into smaller and more manageable chunks. Although, this strategy is used extensively and successfully in numerous distinct areas (legal, business, economics, politics, social sciences) and is the first choice in modern warfare, it seems to fail in IT with flying colors.
By dividing an IT organization a network of small divisions emerges. Although this doesn’t sound bad initially, call to mind that these divisions have almost countless inter-dependencies which make it practically impossible to coordinate all their collaborations. That is what DevOps reminds us of quite plainly.
It reminds us that breaking teams apart due to the division of labor creates separated silos. Silos such as Dev and Ops – or rather, each of their sub disciplines. From a process point of view, this seems to be irresponsible, as the silos create innumerable walls of confusion. Each of these walls interrupt the flow along the entire development pipeline from deployment to stakeholder feedback at numerous distinct positions. Each of these walls becomes a critical barrier to effective teamwork, preventing communication around a common goal.
Does that all simply mean that IT doesn’t understand how to divide and conquer? Or is the IT industry just so exceedingly special that this strategy is simply not applicable?
From our perspective, the latter just seems to be highly improbable. Why, you may ask? We are not the center of the universe.
Interested in the idea of having specialists as opposed to silos? Stay tuned for Part 3 of our DevOps: Nothing Else Matters?! series, delving into the ideas that drive DevOps. Next up: the How, When, and Who of DevOps.