Are Developers finally starting to Understand DevOps?

devops-blog

Software developers remain a curious and opinionated bunch. Over the last few decades they tend to adapt slowly to new methodologies, with DevOps offering little exception to this golden rule. A recent survey reveals things are finally beginning to change, as it shows application engineers beginning to actually “get” DevOps.

Of course, we recently wrote about network administrators feeling DevOps is all about the “Dev” in the first place. What follows is an analysis of the survey to see what these changing opinions mean for the process of software engineering. Perhaps you might gain an insight or two to help your own team’s project work?

Survey says DevOps makes Software Development Faster

Most organizations implementing DevOps do so in the hopes of making their software development process faster and more efficient. A survey of software engineers, CTOs, and IT pros by application maker, GitLab, notes that these wishes appear to be coming true. News about the survey appeared last month on the Developer Tech website.

According to the GitLab study, two-thirds of those polled feel DevOps greatly improves the speed of the software development process. This 65 percent moves upwards to 81 percent when only taking into account the opinion of managers. 29 percent of those surveyed plan new DevOps investments in the current year.

The best shops using the methodology are able to spend at least half of their workday actually writing code. Changes get deployed on demand. In short, these top organizations are twice as productive as those whose DevOps implementation is either immature or nonexistent.

Challenges to Efficient Application Engineering Remain

In their survey, GitLab highlighted a few challenges to the software development process. Two-thirds of the respondents noted the lack of clear direction on application engineering projects. Slightly over half mentioned the need for rework and unexpected scope creep, while 31 percent felt unrealistic expectations hampered their efforts.

Leveraging automated processes to improve efficiency is a high priority at 60 percent of the surveyed organizations. Around 90 percent of those companies are currently using Agile, DevOps, or a mixture of both. 16 percent are still using the venerable Waterfall methodology for some or all of their development work.

Continuous testing also plays an important role in the ultimate success of any company’s DevOps adoption, a concept highlighted by Razi Siddiqui, SVP and CIO at GCi Technologies. “It’s a key indicator that your DevOps/agile practice is mature, and your QA strategy must take into account that 100% test automation is not practical – nor is it possible,” said Siddiqui.

Sid Sijbrandij, CEO and co-founder of GitLab, commented on their survey conclusions. “The survey reveals software professionals finally see the need for DevOps in their workflow and are beginning to adapt their workstyle in order to make this a reality. Despite the progress in the shift in mindset, current DevOps practices are not cutting it. Instead of a single application that accomplishes the goals of both Dev and Ops, many glue together the tools for the two departments, which has proven to be an ineffective means for collaboration,” said Sijbrandij.

It definitely appears that any enterprise software development not using DevOps runs the risk of being left behind in today’s business landscape. Thanks for reading this edition of the Betica Blog. Keep returning for additional insights on the wide world of software development.

Is DevOps favoring the Devs over the Ops?

Group

On paper, DevOps involves the merging of the software development and network operations teams with the hopes of faster application deployment. Companies in a variety of business sectors enjoy competitive advantages because of a successful DevOps implementation. Software engineers and network administrators happily collaborating for the greater good of their employer remains the ideal view.

However, some operations professionals in the industry feel the developers are dominating things too much. Are these the signs of an emerging “civil war” in DevOps? Let’s take a closer look at the details to see if you need to worry about your own team.

Do Network Engineers truly feel Railroaded by DevOps?

A recent article by David Rubenstein in ITOps Times reveals a growing disenchantment with DevOps from networking professionals. They feel the demand by executives for a faster software development process is leading to a lack of control over IT operations. Rubenstein notes that software engineers use DevOps as a cover to “circumvent IT processes that have long protected businesses from costly downtime and security breaches.”

He isn’t alone in this opinion. Lucas Carlson, vice president of strategy at the Cloud automation firm, CA Automic, explains this position in detail.

“DevOps to this day is really built by developers and for developers, and it really feels like a misfit to try to force IT operations to use DevOps tools, given their heritage, because they were built with developers in mind… They’re great for developers but not for IT operations, and that’s kind of created a shift, a divide, and it seems like almost ever since DevOps has been gaining traction and popularity, the developer role within organizations has become more and more raised and lifted. Everybody’s trying to hire developers. Developers are kind of the kingpins of the technology world right now. Developers are held at the highest ranks of where people in technology look up to, and IT operations has really been left behind in all of this,” said Carlson.

Is his view simply a case of sour grapes, a valid concern on the near-future of DevOps, or a mixture of both?

The Traditional War between Developers and Network Administrators

Since collaboration and communication are the hallmarks of modern software development, are we seeing a return to the old days where software engineers and network administrators were typically at each other’s throats? This author remembers a fellow developer regularly called network personnel at our company “setup.exe” in a derisive fashion. He felt their only value involved installing software.

This kind of attitude on both sides forgets one basic fact: development and operations are working for the same team. For his part, Carlson hopes for a new term to take the place of DevOps – AgileOps. Mere semantic changes probably won’t matter, especially considering the strength of DevOps as a buzzword. We’ll see.

Ultimately, these are all likely still the growing pains of a new methodology. Since the executive team controls the direction of the company – and the purse strings – developers and network engineers simply need to collaborate better. A slower approach to the SDLC won’t fly in this competitive Agile era.

Maybe some late Valentine’s Day cards need to be sent between developers and their ITOps brethren?

Keep coming back to the Betica Blog for additional news and insights from the software development world. As always, thanks for reading!

Don’t make Agile Projects a Death March

agile death marchBack in the halcyon days of software development – around two or more decades ago – programmers typically worked longer than 40-hour weeks; sometimes way longer. This is likely still true in some business sectors, especially the video game industry. Over time, however, software engineers began to demand a better balance between their professional and personal lives.

One of the reasons Agile become so popular is its focus on improving the efficiency and productivity of the application development process. Most of this gets accomplished without breaking the programmer’s back. Still, managers need to be reminded not to make Agile projects a death march.

A Recent Trend towards Poor Agile Project Management

In a January blog post for Leading Agile, veteran IT manager, Dave Nicolette talks about a recent trend for Agile project managers to overwork their team to get projects into production more quickly. This traditional “Death March” approach was criticized by the industry legend Ed Yourdon in a 2003 book of the same name. Nicolette notes this management style is now being championed by younger PMs responsible for Agile project delivery.

It seems a book from 1987, Crunch Mode: Building Effective Systems on a Tight Schedule, is the current flavor of the month in some IT manager circles. As Nicolette sarcastically comments: “Reviewers [on Amazon] think it’s great that there’s a way to break every model of sustainable delivery, planning, and estimation, and force people to deliver on an arbitrarily short timeline regardless of the human cost.”

The Risks of the Death March Project

Death March projects happen when the scope of work and timeline don’t match the amount of human resources assigned to the project. In this case, project managers and software leads forego a standard estimation process and simply dive right into the work. Traditionally, this leads to a greater number of errors and the gradual siphoning of employee morale.

Whether or not the project actually met the accelerated schedule, the damage to the development team is notable, as illustrated by Nicolette: “The days immediately following the project are not normal work days. Some of the survivors decide to change jobs or change careers. Others take care of their new health problems or their divorces. Those who escape with most of their sanity intact swear that they will never again participate in a Death March project. They will not be available the next time management asks for volunteers.”

Working Smarter remains more Important than Working Harder

Agile projects, especially those within a company following the DevOps framework, focus on a sustainable process. The overall well-being of all technical resources simply matters more than faster project delivery. “There’s a common mischaracterization of Agile as ‘going faster.’ If all you really want to do is ‘go faster,’ you’re looking for the Death March approach, not the Agile approach. Good luck with that,” comments Nicolette.

In a software development world where engineers desire a balanced life, simply working programmers to death is the worst approach. If you want the highest efficiency and top notch code out of your team, “Crunch Mode” needs to remain in the annals of history.

Thanks for checking out the Betica Blog. Keep returning for additional insights on the world of software development. As always, thanks for reading!