Software Engineering

 

As we stand here in the fall of 2017, one must understand why DevOps is a critical mission for companies in NYC and around the world. It has quite a lot to do with motivation. Today, I wanted to dig into some motivational characteristics, particularly for some of the key contributors within the DevOps cycle:

Developers are like astronauts. They are curious, imaginative and often thinking about ways to innovate! Completing new features is critical and they are continually moving onto bigger and brighter tasks. Simultaneously, developers usually have a keen interest in searching for ways to make the development process easier!

1) DEV Motivation: Get Feature M complete and correct as soon as possible

System administrators are like aircraft pilots. They are not going to be doing flips in the air but rather put the highest priority on passenger safety. Any shift in course should be well-documented and proven beforehand so that a steady approach is pursued. The logical hand is key, and thinking about the future is encouraged before adopting a new idea so that it can be efficiently sustained for end users.

2) SYSADMIN Motivation: Make sure Feature M does not decrease uptime upon deployment!

QA analysts are like eye doctors. They examine and look for potential defects that may have been created in the development process. Expanded sets of various tests that allow for early detection are critical, as any defects that get past these gates can potentially reach production! This places a high level of importance on creating detailed test strategies to set excellent opposition to incoming builds, from all angles and directions possible.

3) QA Motivation: Find and resolve as many defects as possible in Feature M, before it hits production

Examining our three motivations above we can conclude a few things. The first is that the more changes developers make, the more they are accomplishing in their route to new features. Another is that the more changes system administrators receive, the higher degree of risk that uptime may be damaged. These two motivations directly contradict each other, and must be addressed effectively in the DevOps model. In a true DevOps strategy, both teams must be held accountable for both of these goals in order to deliver as a single team with one heartbeat and motivation.

When two opposing forces exist, which are typically monolithic teams that develop very strong bonds with each other, then there is no single uniform mindset. This contradicts DevOps and has been how the world of software has been for quite some time. CIOs and other high-ranking leaders who have realized these key contradictions in motivation and take action to correct them may very well be able to enhance their DevOps portfolio without spending a nickel …

… which leaves a lot of extra investment for potentially shifting container and VM workloads off-prem! A future InRhythm blog iteration will cover just this, steering us away from motivation and into the Cloud(s).

Justin Van Wygerden
Cloud & DevOps
InRhythm