Before we dive in, I will paraphrase my wife’s late grandmother who lived to 102. When asked why she seemed to have so few “disagreements” with people she answered “I make sure I know what they are asking before I answer.”
The last ten years of helping companies adopt processes has shown me that 90% of all successful processes are anchored in “we understand what the other person is asking so we understand what they need.”
From the Software Design V to….
Over the last 25 years the Software Design V has been the default graphical metaphor used to explain the software release process. Down from requirements to implementation, the V ramps up through testing, and finishing at release. Early V was strongly linked to the waterfall development process. As criticisms of waterfall development processes emerged, the V adapted by adding “feedback loops” between parts of the V. As agile emerged the V continued to evolve; agile’s small fast development cycles required smaller faster V and we entered into the ΔV territory. In the last 5 years with increasing prevalence of over air updates and development in the cloud, developers’ needs “broke” the V.
New shape, same objective
If you read a list of the benefits from adopting DevOps you could be excused for thinking they were the benefits of an Agile, Design V, or even a Waterfall development process.
- Improved reliability
- Increased scalability
- Simplified & improved collaboration…
The fact there is so much overlap is not as a criticism of the DevOps, it is the recognition of the underlying purpose of all processes: promote clear communication between the stakeholders in the process.
So why do we need DevOps?
There are more lines of code in a modern dishwasher than in the entirety of my first car.
But it isn’t the size of the code that drives the need for DevOps.
The mathematics equations associated with a LIDAR system outstrips the complexity of the Apollo moon shot by multiple orders of magnitude.
But it isn’t mathematical complexity that slings us round towards DevOps.
The simulated hours of testing for a robotic vacuum cleaner is greater than the total time in pig models for the first artificial heart.
But it’s not the number of hours spent in simulation that is primed the pump in favor of DevOps.
So why do we need DevOps?
It is about clarity of communication. In all of the cases I listed above it was “like talking to like”; controls engineers working with controls engineers, AI people with AI people, testers with testers. The need for DevOp is driven by the interaction of groups that have not historically worked together. DevOps becomes the common language and process bridging the groups.
Feedback loops and continuous integration
The brilliance of DevOps is that it found a point of intersection between the deployment and controls groups. The process connects the concepts of Feedback Loops (controls) and Continuous Integration (development): the “X” point of the DevOps cycle. It is at that point that a common ground and common understanding is easiest to achieve.
This brings us back to the start of this blog; when you are trying to solve a problem you need to understand what the other person is saying. As the software release and update processes become more interconnected across multiple groups, the way we solve them is through the implementation of a common process and vocabulary
One thought on “DevOps”