DevOps: It’s All About Working Together

When businesses want their software engineering teams to implement new practices, they tend to be guided by the most attractive and complex activities. This approach is not surprising in that it makes the rest of the world see the team is doing its work in the most innovative way and is not lagging behind other companies.

Many times, this phenomenon occurs for similar reasons that drive the emotions of software engineers: nobody wants to be left behind in a world where things change every hour. Missing the latest technology train can be the difference between being part of a community or even landing a dream job. This leads to software engineers to first look to belong, rather than to do what’s most practical.

Other times, companies are guilty of similar behavior. To stay competitive, they think they need to deploy the latest and greatest technologies. This tendency to quickly adopt new practices or new technologies can actually lead to rival companies gaining a competitive advantage that cannot be shortened later.

And so businesses begin to implement things that are not fully understood. In other words, they give more importance to activities that give the appearance of adopting the latest trend. And in doing this, they often neglect the more subtle but equally important aspects.

In the case of DevOps practices, these subtleties go beyond new technologies, the most innovative protocols, and the most flexible (or strict) processes. We are talking about questions that apply more to people’s behavior, through applying a philosophy, which by itself may not be seen with the eyes, but whose results are fully palpable.

The Magic of Cooperation

The saying goes that two heads are better than one. And in a way, you can extrapolate that saying to the world of software development. For example, in eXtreme Programming, there’s the popular practice of Pair Programming. It gives you the power to improve your code and to be more efficient than if two software developers worked individually.

Following this line, let’s now imagine that work areas are individuals who can cooperate. That spirit is the main reason for using a DevOps approach. So much so, the name is the combination of two areas of the software development world: Development and Operations.

The main idea behind DevOps is to put aside the separation of these two areas and have people work together, taking advantage of each other’s strengths. Thus, you have developers releasing code to environments that they would not normally have access to, and they can see and monitor the behavior of the software in the final ecosystem.

On the other hand, you also have systems engineers reviewing source code while it is developed. This makes it possible to find defects even before they appear in production or test environments.

Taking advantage of this cooperation brings benefits such as reducing release times and increasing knowledge among team members. Both benefits reduce dependencies on specific individuals and can optimize applications more easily.

Mistakes and Successes Belong to Everyone

Working together brings the additional effect of increasing camaraderie and labor relations. It also improves communication and relationships among individuals. This is especially visible when things are working well: people see themselves as a single team meeting goals and achieving better and better things.

However, the benefits are also palpable when problems are detected; the team can respond together. Gone are the individual statements of responsibility. Anyone on the team can correct a bug or problem, or they can ask for help in case they need it for a specialization that they do not master.

It is important to always recognize the DevOps entity as one, both in celebrations and in times of difficulty. The intention is that the team continues to reinforce this idea—so the spirit of DevOps remains and is reinforced as a work philosophy. You cannot just acknowledge contributions from a particular individual or, worse, publicly point out someone who made a big mistake.

So, Where’s the Automation?

Part of the importance of DevOps practices includes what I mentioned at the beginning of the article: Taking advantage of new technologies and tools is essential to implement DevOps properly.

For example, if you use tools that facilitate source code control, that makes many of the code reviews and release tasks automatic. It also allows you to quickly monitor the performance of your software in operation. You will be able to do (and show off) those super-fast releases multiple times a day.
In addition, your work teams will be able to focus on what is really important: producing quality software that solves the problems of users.

If you have any comments about DevOps, I welcome the opportunity to hear about your experiences. I’m also glad to answer any questions you have about implementing or fine-tuning a DevOps process for your software development team. Feel free to contact me at