Excessive amounts of anything can prove detrimental. One of the core parables within sci-fi is predicated on the principle that applying too much of anyone's practice will inevitably lead to a utopian or dystopian society. The same is true when it comes to software engineering.
In her recent chat with the Patrick Debois—author of "The DevOps Handbook", researcher, and one of the originators of DevOps itself—, LaunchDarkly's CEO, Edith Harbaugh, discussed what happens when we attempt to go excessively "all in" on specific methodologies. When talking about the practice of identifying and, more importantly, removing bottlenecks, Harbaugh states that when we talk about DevOps, it's vital to bear in mind that "it's a methodology, not a cure-all".
The two sat down towards the end of 2021 for a fireside chat to discuss the practice of optimization following the release of the second edition of "The DevOps Handbook." In discussing how things should be done, naturally, the inverse became an integral part of the discussion. After all, in order to properly define what something is, we must also qualify what it isn't.
What DevOps is and isn't
When it comes to definitions, the term "DevOps" is infamous for meaning different things to different people. Some view it as a series of processes, others as a way of thinking. Having originated the term, Debois determines that "DevOps is whatever you do to bridge friction created by silos, all the rest is engineering."
As is the case with all movements, they often tend to absorb the momentum they gather and, once in motion, take on a life of their own. On the broad adoption of DevOps, Debois notes that he tends to "have a different origin on why I got into DevOps" compared to others. He adds that "a lot of people got into it to improve their business and to get better results or faster to production. I came from being in love with the Agile teams, human treatment, and the people treatment. And, for me, that's always been the core of how I build on top of that for DevOps. So I would look at the tools and think, "What benefit do they bring me in bringing humankind of improvement? I don't see that being reported in that way."
The same can be said of movements within the development world that have both followed and preceded DevOps. Take Agile, for example. Harbaugh notes this, adding, "I started my career when agile was still new. And then it became very regimented. To the point where I remember Kent Beck commenting on a mailing list on lean startups, stating that "agile is a capital 'A' now, where I always wanted to be little 'a.'".
This cyclical nature towards service-level consumption, or even the reduction of a mentality to a set of practices, seems almost built-in to engineering as a discipline. As Debois notes, we're starting to see this happen with the Google-funded function of the Site Reliability Engineer, or SRE for short. He notes that the "SRE mentality at the origin is no different from DevOps is no different from Agile is no different from ITIL. They all meant to improve and make things better. But what tends to stick is the practices that people remember around this, and SRE will always be like SLOs, as flies and kind of those practices. DevOps will be containers and conflict management and monitoring. Agile will be TDD, and so every one of those movements kind of got reduced into a set of practices that people remember it for, but at the origin, they're kind of saying the same thing."
Within "The DevOps Handbook," Debois speaks of Conway's Law, which states that "organizations, who design systems, are constrained to produce designs which are copies of the communication structures of these organizations." This reflective construct can be extrapolated out to explain what happens when we adopt methodologies en masse. As product builders, it's in our nature to productize what we know. Is it any wonder that agile became Agile? To make these constructs consumable, we often need to capitalize them both in name and nature.
Achieving long-term, generative growth
The other inevitability of a movement is always its demise. A few years ago, in a blog from its SmartCloud Engineering Team Lead, Smart Parking, Google Cloud determined that DevOps was essentially "dead", dubbing the advent of serverless as its supposed killer. Despite many factors pointing to it being very much alive and well, Debois doesn't outright refute this claim. He notes that "people have started equating DevOps with certain practices, as I mentioned before, with Agile with TDD, and so on. So people will equate it like 'we're doing containers' or 'we're doing this and that'... things will get abstracted, and there's gonna be different practices."
Data backs this sentiment up, with the latest instalment of Puppet's "State of DevOps Report" reporting that we appear to have collectively reached "peak DevOps" back in 2018. Regardless of the name we give it, the process of overcoming silos and removing bottlenecks isn't anything that's likely to go away. Whenever we give rise to a specific practice, the temptation is often to achieve mastery, begging the question, when does DevOps become counterproductive?
To understand the inflection point of when we falter and potentially lose sight of the problem, we only need to turn our eye towards batch sizes. Debois notes, "I think the overall problem is that we try to cram 100% utility, but if you probably estimate for 80% utility, you will have a much better life and much better flow". Our inherent ambition sometimes leads us to believe that everything else will slot into place if we can conquer the method. If we master the 'how' and throw everything at the problem at hand, we can transfer this approach to various other problems.
But being the best at doing something on its own won't guarantee success. As Debois comments, "The technical implementation, and nailing how to do things better won't ensure that your company succeeds". He adds, "Sometimes I get the impression that teams go completely all-in on this one problem, but they're not constantly re-evaluating whether or not that's their biggest problem. People do this with the cloud; they put all this effort into being on it when the problem is bleeding through somewhere else. Maybe security, for example. The metaphor that I try to use for describing it is, I think like, a barrel, you have the sides, but if one of the sides is leaking water below the level of the others, that's the one that needs plugging, and there's no benefit of having like one side, up until the top. So it's like you always go around, looking at all the aspects to improve them incrementally in that way."
Wherever we look across the development lifecycle, focusing on incremental, iterative progress and consistently staying open to learning is the best way to achieve long-term, generative growth. Simply doing more and adding more won't always produce a greater yield of results. He elaborates on this notion, adding that "the experience from developers is that it's an art as much as to add features to it than it is to remove features from the backlog. Sometimes not doing something is sometimes really hard."
The approach of more not always being more certainly rings true within feature management. It's often said that the best communication from your users comes in the form of them consuming what you make. While user research can often prove pliable to the notions we believe accurate, the proof is always in your products' metrics, click-rate, and consumption. If your users don't gravitate towards a feature, then the chances are that it doesn't resonate. As Harbaugh notes, "if a feature doesn't get communicated on, and if it stale for two months, it's probably extremely unlikely to get shipped at all."
As technologists, refining the 'how' of a process is where we find comfort. Perfecting that "one best way" can feel like an achievement, but the real prize comes when we embrace our pliability as humans and factor it into our processes. By always staying open to improving the way we work, we'll strive to do better than our best, forming a recursive improvement loop. It doesn't even have to be DevOps per se. We can borrow from SRE, resurrect ITIL or even adopt both the upper and lower case of Agile. As long as we retain our drive for improvement and reinforce the response to our feedback loops, the impact of our efforts will materialize.
You can head here to catch Patrick Debois and Edith Harbaugh's discussion in its entirety.
.webp)
