Why does development oppose operations?

Question

I'm still a student, but I'm not knowledgeable about operations, and my English is still bad.

My question is: Why does development oppose operations? When does developing oppose operations?

Answer 1

The point of DevOps, is that development shouldn't oppose operations, instead they should support each other.

Traditionally, due to waterfall deployments and large scale updates, development would cause operations a variety of problems when deploying due to inadequate testing, changing server environments, the list goes on and on. Essentially, the updates were too large for the operations team to be able to effectively deploy them without some problems arising in the process. These problems might be why you believe that development opposes operations.

On the other hand, DevOps works to reduce update size, decrease rigid environments, and generally improve the handoff of the application between development and operations by increasing the amount of times the handoff occurs each year. With the increased number of deployments comes less headaches for operations, because they have either automated a large amount of work required to update the products, or they better anticipate and prepare for the updates.

Tldr: DevOps aims to nullify the theory that development opposes operations by creating a mindset where operations and development work together to frequently deploy products in a timely and easily reproducible way.

Answer 2

I think you already got some comprehensive responses, but you said your english isn't great, so I'll try to provide a very brief and understandable answer:

• The primary goal of development is to make changes.
• The primary goal of operations is to keep the environment stable.

These two things conflict. That being said, development and operations should not oppose one another. They should work together to make sure both goals can be achieved. This is the purpose of DevOps.

Answer 3

The tension between development and operations is often caused by misalignment of incentives and attempts to optimize within the team.

Developers are often judged by the speed and quantity of issues they can get through and merged into code repository and their reward is often not tied to that code actually working or working correctly. Much less scaling, performance and other factors.

Operations are often judged on the stability of the environment and how well the code works in production, but rarely on the quality of the process for bringing changes in quickly.

This creates the issue where developers are incentivized to create a lot of code and throw it over the wall to the operations team and the operations team has incentive to accept as little change as possible to ensure the stability of the environment.

DevOps is in a way the set of solutions to this problem:

• Some of them can be organizational, where the processes and incentives of the teams can change. For example if developers work is only marked as done when it has been running in production for some time, there were no issues and the operations team agrees to take ownership of the code. Similarly operations can be judged more on the speed with which the code is being accepted, while the environment is still within some bounds of stability.
• Another part of the solution can be in communication and cross-polination, where you embed operation people in development team and vice versa. You break the wall between those teams and DevOps engineers are often the result of this type of bridging.
• Tools supporting processes like Continuous Integration and Continuous Deployment are another part of the solution, which can increase the speed of changes, while retaining high quality and fast recovery of the production environment in case of any issues through rollback of code or fast progress of a fix into production.

Answer 4

Most organizations deal with complexity by breaking down their organization into functional parts and demanding that each part figures out how to improve itself. This is often called the "silo" approach.

It is important to understand why this silo approach blocks the success of the business and often fails to improve the organization as a whole. And it doesn't affect just development and operations - it affects all the other functional silos within a large organization such as quality assurance team, finance, product and project management.

As managers of each functional silo are commanded to improve by cutting cost or increasing speed, their reaction is often:

• I am totally overwhelmed fixing problems from the last improvement effort. Leave me alone.
• What do you want me to do, fulfill my responsibilities or work on improvement projects? I do not have time to do both.
• Not again! Here comes another program of the month.

With these typical reactions, any executive launching a minor improvement effort is rarely greeted with enthusiasm. Managers find themselves in fierce competition with other functional areas over resources needed to execute their improvements. So, no wonder the command to improve intensifies cross-functional battles!

Even when a manager completes his part of an improvement project, he then meets other functional areas and other organizations (suppliers, contractors, etc...) that did not do their job. This diminishes or totally negates the results.

This cross-functional tension is not limited to improvement efforts. It is in the very heart of day-to-day decision making and the judgment of management effectiveness across an organization. Here is one real-life example:

A finance manager was told, "improve." He decided to block hiring contractors that cost more than the nominal price accepted in the market. He implemented the new policy and claimed to have saved $1 million dollars this year. With developers and IT unable to hire contractors to help them use container and container orchestration since these contractors are expensive. The IT operations manager in the same company calculated that not improving in their infrastructure was costing the company well over $100,000 in extra expenses each month. At that rate, the annual savings in hiring contractors were eaten away before the year ends.

You can imagine that the relationship between these two functional areas was not exactly lovey-dovey.

These cross-functional conflicts are driven by the silo approach, where the organization measures each silo in improvement independently. If you are a cost center, improvement naturally means greater efficiency or cost reduction within your silo.

In this frame of reference, costs are seen as obeying the "additive" rule. The costs of each silo added together, equal the total cost of the organization. Therefore, managers see any cost reduction in their area as "good," since they see a direct translation to cost savings for the company as a whole. In this frame of reference, improvement efforts are spread everywhere to attack cost and waste throughout the organization.

A great example when the development team/s start working Agile and pushing code to QA and Operations every two weeks instead of every quarter like they used to. The QA and Operations are not ready for such a change and are blamed for slacking off. Again, this does not contribute much to the love between the people in development and operations.