Technology vendors and enterprises continuously experiment with new ways of software delivery to ensure the software is bug free, meets the timeline and cost objectives, and can be updated going forward. For this to happen, multiple teams within the software development ecosystem need to collaborate and talk the same language. Enter DevOps.
While the Agile methodology was a meaningful initiative to address the time-to-market aspect of software, it didn’t serve the entire purpose, and release management and operations continued at a sluggish pace. Developers were developing code, but it was rarely delivered into production at the same pace despite “continuous integration” being around for ages. DevOps tries to address this disconnect ensuring tasks such as provisioning, configuration, and security are automated and simple. It attempts to bring different moving parts and teams in an application lifecycle onto the same page, working toward the same target, using the same terminology, and – possibly the most important – working with the same underlying infrastructure.
Opponents think DevOps is a bad idea and much more applicable in startups than enterprises. Not surprisingly, proponents believe this to be a loser’s argument from large organizations and one more excuse not to evolve their archaic systems.
From a software developers’ perspective, DevOps is met with a mixed bag of reactions. Very few developers truly understand it (they are busy coding, their work), some believe in its promises, and some are skeptical. The skepticism comes from the perception that DevOps is trying to shift the onus of managing databases, application servers, and systems to the developers. It is trying to make them what is popularly known as “full stack” developers, superhuman developers who are a data base administrator, a system administrator, a security administrator, and other things all in one.
Many software developers believe that DevOps will add to their already burgeoning overhead, rather than helping them write code that can create great software (I discussed some of this in an earlier blog where I made a case for allowing developers to be more crafty, rather than tied to rote coding). While some senior developers believe it will ensure better time-to-market, reduced cost of quality, and collaboration between teams, they are apprehensive about the role they have to play in this entire game. Though developers do not like raising tickets for everything, and prefer quicker access to infrastructure – which is a key driver for the adoption of cloud services – most developers believe DevOps may be taking things too far for their liking. They also believe that the onus to improve the entire application delivery process is being put on their shoulders (and they’re not at all pleased with that and believe that they are being asked to address IT operations’ laggardness.) Moreover, a lot of them just do not want to work “with” IT operations.
Adding to all this is the typical noise around “culture change.” Of course, anything meaningful requires a culture change. However, viewing DevOps only from a culture perspective is like the proverbial can’t see the wood for the trees. It requires as much investment in tools, collaboration platforms, cloud services, release management solutions, and development platforms.
So how can organizations make the developers see the value of DevOps? Cut through the theoretical knowledge and the puritanical message on culture change. Or, call it something other than DevOps. Make the developers see beyond the confines of their code to how it fits into the broader scheme of things. Help them understand the challenges of IT operations, and how those challenges are impacting the software delivery and hurting the business (of course, IT operations also needs to understand the same about developers). Make developers link DevOps adoption back to business benefits and the importance of them adopting such principles. And, finally, have them have some hard metrics and data to track and analyze the adoption. Do not make it a benign exercise in vanity, but rather something more meaningful and tangible.
The industry should keep experimenting with newer ways of application delivery, and throwing the DevOps baby out with the bathwater may not fit into that mix.
