The DevOps movement is driving changes to our organizational structures and amount of automation, and accelerating the delivery of high-quality features to our customers. While all this is awesome, there is a ton of work required to make it happen, with a high change curve to overcome. Typically it involves changing methodologies, organizational design, and technologies, but perhaps the most critical change is to the way the developer works.
Going from waterfall to agile is a change for all team members because it asks you to communicate and work closer as a group. Agile asks everyone to be good team members and start providing more transparency. This can be a little painful for everyone, but for a developer who enjoys the heads-down work of writing code, this is just the beginning of their challenges.
Changing methodologies can impact everyone, but for developers, the biggest challenge is adapting their interaction model. For instance, a key component of DevOps and continuous integration is fast feedback. This means that when I check in code, the build automatically runs, and if it fails, I now need to stop and fix whatever is broken. This process continues until the build is green and will continue through environments, until code is production ready. This constant start and stop can get anyone frustrated, but it’s needed.
It’s needed because we are shifting quality left. By fixing issues in the moment, we are reducing technical debt and are better suited to release into production, early and often. However, this is a tough way to work; no one wants to be constantly interrupted, but especially not a developer.
Because of this constant starting and stopping, I have seen many cases of developers preventing full automation. Even though we had the ability to make things automatic, we had to hold off on full automation because the team couldn’t handle the disruption.
So, what do we do? While having the build and test process automated is good, there is still technical debt building up, which requires some level of hardening at the end of the process.
A manufacturing line, such as the Toyota assembly line, is a great example of why this process is needed. Historically, it used the andon system to stop the line when a defect was found. This reduces the risk of defects at the end of the line, when it is more costly to fix.
For developers, the automation that can be applied to the build pipeline provides that same feedback. While it is disruptive, it is necessary. We can help developers reduce the disruption by ensuring they have the tools and automated tests needed to robustly validate their code prior to check-in. We also need to be careful that, as leaders, we are not just focusing on dev complete; instead, we should focus on working code and passing tests, so that we optimize for feature complete.
DevOps will impact everyone. It’s not just about shifting responsibilities to developers and automating everything. There are technical enablers as well as mindset shifts that have to occur to make it a reality.
