Here's a DevOps nightmare: It's been a few months since the DevOps adoption project was declared completed. The necessary automation tools are in place. Developers and IT operations staffers now belong to one team. They've been instructed to collaborate and communicate at every step of every applications' life cycle. The business should soon benefit from faster and better software development and deployment. Life will be good.
Except that developers are coming to work and feeling as if they're in a house of horrors instead of in Shangri-La. They've got Sheryl Crow stuck in their heads blaring: "If it makes you happy, then why the hell are you so sad?"
Frazzled developers run around, overworked and stressed, exuding a burnt-rubber smell and playing hero ball, because they must now intervene in QA/testing, systems administration, database management, and code deployment and participate in the office's weekly book club meeting.
And what the heck is this cape someone taped to their backs that reads "Full Stack Developer" in big, bright-red, shiny letters?
Emergency, or the new normal?
When such a situation arises, is it a sign of a DevOps project gone off the rails? Or does DevOps by definition call for developers to assume multiple roles and discharge a variety of duties with a certain level of expertise beyond their core app dev skills? Is the truth somewhere in the middle?
As often happens with DevOps, a lightning rod for controversies and arguments, there is no clear answer to these questions. This shouldn't come as a surprise, considering that DevOps is more of a philosophy and culture shift than a codified IT practice. There isn't even an agreed-upon definition of what DevOps is, and all involved accept that implementations are unique to each organization.
Apocalyptic fears: Developers become walking dead
That the issue is real is clear from the spirited reaction to a blog post that Jeff Knupp published last year, ominously titled "How 'DevOps' is killing the developer."
The post received hundreds of comments on his blog, as well as Reddit, Slashdot, Hacker News, and other sites. Many reactions were statements of agreement from developers scarred by having to wear too many hats after a DevOps adoption.
A sample of replies: "I identified with this text and my current difficulties as developer." "Amen to that!!" "Fantastic article! I was going to start honing in on the points I particularly agree with but all of it is just spot on."
"We specialize for a reason: human beings are only capable of retaining so much knowledge. Task-switching is cognitively expensive," wrote Knupp, author of the book "Writing Idiomatic Python."
He complained that piling onto developers' plates multiple roles historically performed by specialists distracts them from their core duties, forces them to keep up with vast new fields of knowledge, and leads to burnout.
"The effect of all of this is to destroy the role of 'developer' and replace it with a sort of 'technology utility-player,'" he wrote. "Every developer I know got into programming because they actually enjoyed doing it (at one point). You do a disservice to everyone involved when you force your brightest people to take on additional roles."
Knupp acknowledged that in startup environments, developers must play many roles due to resource constraints. But he argues that the DevOps movement is trying to export that model to mid-to-large companies, gift-wrapping it as an improvement, when in fact it is far from optimal.
"Please, don't confuse 'being lean' with 'running with the fewest possible employees.' And for God's sake, let developers write code!" he wrote.
Knupp is far from the only DevOps detractor around, especially now that it has become an overhyped industry buzzword, manhandled by marketers, opportunists, salespeople, advertisers, and charlatans. A web search for "DevOps" yields many articles, columns, tweets, comments, and blog posts calling it "bullshit" and a "scam" and clamoring for a definition.
Or maybe this isn't DevOps after all
A key DevOps principle is the adoption of a collegial attitude that creates an atmosphere of trust among devs and ops and a shared sense of ownership and accountability for common goals.
This means that developers no longer fling apps over the dividing wall and go on their merry way, leaving operations to whip the code into production shape. It also means that ops folks are involved in the development work, providing input and advice on deployment requirements.
In other words, there is supposed to be communication and collaboration among all members of the team: devs, ops, QA testers, sysadmins. Instead of staying within the walls of their historical fiefdoms, DevOps participants move around with more liberty and flexibility within the team, helping out in areas they previously avoided?and weren't welcome in?and having a greater understanding of everybody else's roles and challenges.
Does this mean developers have to suddenly become master jugglers worthy of the Ringling Bros. circus ring? No, says Jos? Juan Mora P?rez, author of the book "DevOps y el camino de baldosas amarillas" ("DevOps and the yellow brick road").
"If you end up with a situation in which a team takes on tasks and responsibilities for which it isn't prepared, we can't say there has been a DevOps culture adoption," he says. "It may be something else, but it's not DevOps."
Mora P?rez points out that DevOps is implemented, by definition, to ultimately solve business problems and achieve business goals via better, more frequent software services and products. If while trying to increase IT agility the organization sacrifices IT quality, the business will suffer.
"That contradicts the DevOps philosophy," he says. "DevOps doesn't propose that everybody knows about everything, but rather that teams communicate and collaborate with each other."
OK, so how far must they extend their skillsets?
How much, say, testing should a developer do, and of what sort? What is the right level of involvement in operations for a developer? Does the "full stack" developer have a place outside of startup environments? The answer, according to IDC analyst Stephen Elliot, is that there's no right answer. "Every organization and project is different," he says.
That doesn't mean that anything goes, however. The stakeholder executives in charge of planning the DevOps transformation in the organization must decide, according to Elliot.
They may choose to redefine roles or not, after assessing the skills, aspirations, motivations, talents, and background of the people involved in the DevOps project. For example, one company may decide it wants several "full stack" developers on board, and another may go ahead with none. In the end, these leaders must make sure everyone is on the same page.
"It's up to the executives to shore up roles, responsibilities and expectations so the teams and the people involved are clear about what they're being judged on, the transparency of the metrics that matter and how everyone needs to work together," Elliot says.
Jonathan McAllister, author of the book "Mastering Jenkins," says DevOps can be doomed from the start if the leadership team lacks clarity about the reasons for embarking on the project and misunderstands fundamental DevOps concepts and principles.
In these cases, the leaders misapply DevOps "as operations people who can code or development groups who become operations' on-call personnel," says McAllister, who has a decade of experience in software development, test, and delivery practices. "When applied correctly, DevOps has a tangible business impact and provides value. When misapplied, it can cause more problems than it solves and can fundamentally make an organization's culture worse," McAllister says.
Once the right people are on board and the roles defined, it may be necessary to invest in training them so they can develop new skills, Elliot says.
Don't run for the hills at first take
A certain amount of turbulence is to be expected on the climb to full cruising DevOps altitude, and then smoother air will be the norm, McAllister says.
The higher levels of communication and collaboration that DevOps triggers can cause distractions at first among team members that previously only focused on their own tasks and now have to get involved more broadly.
However, this shouldn't be seen as an individual burden, nor as a sign that the DevOps adoption is flawed. "When DevOps concepts are applied properly, it's about team members helping each other and learning each other's specialty skillsets," he says. This eventually results in benefits, including a higher awareness about other people's work challenges, and more empathy among co-workers. It will also yield higher-quality software releases, faster development, and business successes.
The grass isn't always greener on the ops side
If developers are feeling out of sorts and experiencing an adaptation process after a DevOps project, they might find comfort in knowing that their operations counterparts often have it much harder, according to Jay Lyman, a 451 Research analyst. "Most of the disruption in DevOps is on the IT operations side," Lyman says.
Central IT and IT operations teams must transition from a narrow focus on stability, command, and control to a more modern approach, leveraging automation and cloud computing to be more responsive to developer teams, he says.
In fact, when IT operations teams lag behind, developers sometimes become impatient with the pace of software deployment and get involved with infrastructure management. "This is where they can get bogged down in tasks other than their primary focus of software applications," Lyman says.
As the organization transitions to a DevOps way of working, hiccups are to be expected, and a perfectionist mentality can be counterproductive. "Organizations must realize there will be failures," he says. "The goal is to be technically fit and iterative enough that a failure is merely a blip on the screen amid many more successful releases."
Suck it up, devs, and embrace your role
Asked whether developers are sometimes put in a difficult, juggler's position, Christian Posta, a principal architect at Red Hat, answers with a dose of tough love for his peers, saying good-naturedly that he rejects the question's premise.
"Testing, quality, communication, domain, etc., are all the responsibility of the developer and developer teams," says Posta, who has hands-on DevOps project experience at a large Internet "unicorn" and at a handful of enterprise companies in North America. "We want to improve quality and increase feedback loops and, in terms of implementation, that starts with the developer."
Ultimately, developers can't lose sight of the reason why DevOps has become so popular after early adopters like Google, Etsy, Facebook, Amazon, and Salesforce swore by its benefits: Businesses must ship software with more speed and quality to remain competitive. Now, companies outside of the tech industry, including Target, Disney, Nordstrom, Ticketmaster, and Capital One, have started adopting DevOps and reporting encouraging results.
There is pressure on all employees, and on developers in particular, because it's very costly in more ways than one to a business to have a software product or fix ready that is delayed in getting to its customers, according to Holger Mueller, an analyst with Constellation Research.
And like it or not, warts and all, DevOps is transforming software development, and there's no turning back, as Jim Bird wrote in a reply to Knupp's lament.
"Developers?and their managers?will need to get used to being part of the bigger picture of running IT, which is about much more than designing apps and writing and delivering code," Bird, a software development manager and CTO, wrote in a DZone column titled "DevOps Isn't Killing Developers?But it is Killing Development and Developer Productivity."
"This might be the future of software development. But not all developers will like it, or be good at it."
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
