Two Misconceptions About DevOps

Thanks to the success of DevOps since its inception in 2009, the software industry has generated a wealth of information that helps software teams understand how to take advantage of these great practices and improve the results of their services. The industry has also benefitted from a large number of tools that make day-to-day development and operations work much easier while also helping provide services for customers to enjoy.

However, with this sea of information also comes misconceptions and misunderstandings. That’s because it’s easy to misinterpret what the creators of DevOps tried to express when they revolutionized the industry with their new concepts.

Thus, it is important for teams who intend to apply DevOps practices to discern the difference between what it really means to apply DevOps to their work—as opposed to what may be a misconception that could hamper their efforts to implement improvements. Getting DevOps wrong could cost valuable company time and resources that may never be recoverable.

In this article, we discuss two concepts in particular that are often confusing when a software team tries to apply DevOps within its software engineering processes. This especially true when a company does not have the appropriate guidance or advice from DevOps process experts.

Misconception #1: DevOps Won’t Fix Every Team Problem

No doubt, the concept of DevOps is very powerful. And when applied properly, DevOps can take your team to the next level of code release ability, problem identification, problem-solving, and in general, teamwork. But on its own, DevOps only focuses on these software-engineering aspects.

Other problems in other areas require other solutions. For example, if a software product designer has trouble identifying the best way a user might interact with an application, DevOps doesn’t offer much beyond the quick feedback that comes from the result of the initial release. But to get to that point, there must be a first version that you don’t yet have!

Thus, this is a problem to solve with better product definition practices. It will be useless to have the newest DevOps tools to release applications running on the most powerful cloud services if you do not have everything needed to achieve success. These include a good work methodology, an appropriate platform to implement the practices, and a well-trained team, which are all excellent complements to DevOps. Together, they can bring the work of software engineering teams to success.

You should also be careful if applying DevOps just for the novelty—believing it will solve every one of your deficiencies. DevOps helps greatly, but it is just one of many things to bring to the table to help your software team.

Misconception #2: Beware DevOps Teams

Probably the most widespread misconception on this topic is the belief that companies need to have dedicated teams to implement DevOps. This is derived from the additional knowledge that involves configuring the necessary tools to take full advantage of the benefits of DevOps. The concept also emerged from the habit of commercializing any new fad in the software industry, which led many companies to select “dedicated” engineers for DevOps.

These engineers often get grouped together in work teams that act as a “bridge” between the Dev team and the Ops team. The problem with this approach is that it further compounds the problem that DevOps was originally intended to solve. Instead of fostering development and operations collaboration as a single team, the practice of creating DevOps teams can increase this separation even further.

However, the idea of DevOps roles is not entirely wrong. Many Agile development methodologies rely on multi-disciplinary teams. And this concept can be applied at different levels. Thus, as long as a methodology is well-defined, and it is understood that everyone must work as a team and is responsible for the results—there should be no problem assigning engineers to specialize in the tools and concepts necessary to apply DevOps.

Just don’t forget to share that knowledge with others!

What Is Not Ready Today May Be in the Future

It is worth closing by mentioning that misconceptions like these are not unique to DevOps. Practically any new and successful idea that emerges from a community—rather than an institution—runs the risk of transforming its original message. This is similar to a phone chain where the message changes as it goes from person to person. Without a single authority to regulate the message, disruptions are almost inevitable.

Such is the magic of the communities we enjoy today in the software industry. And this malleability also facilitates the improvement of practices through its users. After all, it was through a community that DevOps was conceived and communicated.

So who knows? Perhaps the evolution that the community brings us to later will be so radical, it breaks with the current conception of how we should do our work.

If you would like to share your DevOps experiences or have any questions about implementing DevOps processes, I would be glad to hear from you. Feel free to contact me at