Monday 17 April 2017

Shift Left


All software is delivered into production via some kind of pipeline, these pipelines may vary in length, complexity and effectiveness but they are the route a team relies on to deliver value.
A pipeline may start on the left with a connection to source control and end on the right with a connection to your production environment.
The goal of any introspection of this pipeline should be to shift more and more of the activities it performs further left. Obviously certain tasks, such as deployment, have their position in the pipeline dictated by practicality, but any activity concerned with quality should be as far left as possible.
Early Enforcement and Education
Once sub-optimal code is allowed into a code base a certain amount of technical debt has been incurred, the further right this code goes in the pipeline the higher the cost either in terms of impact to customers if it gets deployed or overhead for developers who must try and fix it.
Automated enforcement of quality as far left as possible in a pipeline is an easy way to try and reduce these impacts, possibly to nothing.
If this enforcement can be at the point of a pull request we can ensure that these sub-optimal changes don't even make it into the mainline trunk.
If it may seem a little heavy handed to place these barriers in the way of developers then they can also be viewed as automated opportunities for education.
If a problem with a change is pointed out early to a developer it gives them an opportunity to learn the why and how of how they can improve the code they are submitting.
If sub-optimal code makes into production these lessons are often more painful to learn and have much bigger consequences.
The Grey Area
Whenever new code is submitted a grey area opens up where we are less sure than we were about the effectiveness of our code in doing what it is designed to do.
If your pipeline does little to enforce quality on the left hand side then this grey area extends all way to your production environment.
The goal of moving quality and testing activities further left is to reduce the size of this grey area to be as small as possible and to get us back to a comfortable feeling as quickly as possible.
Uncertainty in the state of a code base is a bad place to be, not only does it open up the possibility of shipping defects to customers it can also hamper further progress in delivering new features as developers become more tentative in the changes they are willing to make.
Without having a pipeline that is testing, analysing and deploying code on a regular basis this grey area will grow in the build up to you pushing to production creating a fog of fear for everyone involved.
Before You Move On
Developers do and will make mistakes, any strategy built on the idea this can eradicated will fail.
Another goal of shifting left is to highlight when mistakes are made much earlier.
If these mistakes can be pointed out before the developer moves on to their next task the cost of fixing the mistake is likely to be greatly reduced.
Developers tend to get absorbed in their current task and can very quickly forget the details of anything they've done previously.
When mistakes are brought to them when the code has progressed further through the pipeline a large amount of time is likely to be lost as the developer shifts context to re-educate themselves on the change that is causing problems.
If the mistake is highlighted a matter of minutes since they submitted the code they will likely very quickly curse their stupidity or oversight and apply a fix.
Within software engineering we are lucky that the production process for our output can be made extremely fast and easily automated, this gives us a unique opportunity to recover from mistakes and improve quality on a rapid cadence.
Many other engineering disciplines where build time maybe measured in hours, days or months would likely kill for this opportunity.
Embrace this gift that we have and attempt to take it to the nth degree by moving these opportunities ever further left in your pipeline.

No comments:

Post a Comment