Why everyone hates DevOps
Even though DevOps is widely seen as a powerful way to create better software faster and more efficiently, it puts new pressures on all parts of the organization.
The IEEE’s DevOps Unleashed symposium last week was dedicated to providing “expert advice on how to innovate faster by accelerating software delivery across the enterprise.” The implication was clearly that DevOps is a great way to do that, and I totally buy into that assumption.
But the presenters at the event at Mountain View’s Computer History Museum spent a fair amount of time talking about the origins of the widespread resistance to many real-world DevOps implementations, and how to overcome people’s perfectly understandable fears that DevOps will turn out to mean harder work for everyone—and more of it, too!
“It’s only natural,” said presenter Jez Humble, vice president at Chef and co-author of a pair of DevOps-related books (Lean Enterprise: How High Performance Organizations Innovate at Scale, and Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation), because DevOps puts new demands on all parts of the organization.
042815 devops symposium ieee
How DevOps affects business people
In a DevOps environment, business people suddenly have to spend a lot more time talking to engineers, Humble said, a task that they may not always appreciate. Busy marketers, for example, may not be inclined to spend their time worrying about technical matters that they used to be able to ignore.
How DevOps affects developers
Software engineers, meanwhile, now have to talk to the business people. And in many cases, Humble noted, the whole reason people became engineers is so they wouldn’t have to talk to other people.
And that’s only the beginning of the changes that developers face. In many organizations, developers are typically measured on simple (if often silly) metrics like how many lines of code they write, Humble said. DevOps presents a new and much more complex set of developer metrics.
How DevOps affects IT operations
The folks who work in IT ops in a waterfall development environment are probably used to have “something nasty coming over the wall every 18 months,” Humble said. In a DevOps environment, “now it comes over all the time.” Even though those releases should be profoundly different than a waterfall release, the most common reaction from ops people, he noted, is, “Please make it stop!”
What to do about it
For most people, the natural reaction is to create a barrier—which in many organizations takes the form of the change management practice. “The goal of which is to make sure that change never happens,” Humble claimed. That resistance is easy to understand: People are afraid of failing, of losing their jobs, Humble said, and a lot of companies have used lean principles (including DevOps) as a “metaphor for firing a lot of people.”
If people are afraid, Humble said, “they do everything they can to block you, to bring the whole thing to a halt.” To keep that from happening, he said, you have to make it clear that this kind of change is not about firing people or reducing headcount, but about learning new skills and taking responsibility for what you do.
The symposium presenters noted that developers like to whine about how DevOps makes them spend all their time testing and leaves them no time to write any code. That can be an issue, Humble noted. “But it’s better than developers writing code without caring how it works in the real world.”
“Devs aren’t stupid or evil,” he concluded. “But if they never experience the consequences of their actions, they can’t get better at it.”
Best comptia A+ Training, Comptia A+ Certification at Certkingdom.com