Let’s talk about a practice that allows you to deliver better and faster software. “Shift left” is a buzz word, especially when it comes to software testing. But shift left what and where?

Orientation - what is left and what is right?

The creative process usually looks like so:

To create something of value, there’s usually a bunch of steps that lead to the final output. These steps are part of the creative “process”. Of course, the above diagram is a gross simplification, usually the creative process looks like the following:

Here, we have added feedback loops. Each step of the creative process involves collecting feedback, and you would have to incorporate the feedback by either redoing that step or even multiple steps before that step. The further along that you are in the process, there is more risk involved in redoing all the steps before it. This highlights an important fact, that feedback is easier to incorporate the sooner you discover it in the process.

The “shift left” practice takes advantage of this fact and encourages you to collect feedback earlier by moving critical steps to the “left”, i.e. earlier in the process. Such a practice helps you reduce risk and deliver faster by avoiding unnecessary and costly delays and rework.

Software testing

The usual canonical example is the replacement of manual testing with test automation. In a phased SDLC, manual testing is an expensive and time consuming activity that follows development. A defect found during such testing requires it to be triaged, documented and communicated before it is actually fixed by the developer. Writing automated tests and running them in a Continuous Integration pipeline helps the developers self-discover issues as soon as their code is checked in. This results in a shorter and faster feedback loop, preventing a large set of issues from passing through unchecked for manual testing.

While “shift left” is often invoked in the context of software testing, it is a general practice that has applications in many other aspects of software development.

DevOps and Containerization

The adoption of containers across the industry as the defacto runtime artifact has brought with it many advantages. However, it is also a fine example of shifting left in the DevOps world, enabling increased flexibility for the developers to define the environment in which their programs run.

Let’s contrast this with the pre-container world to understand better. The Ops team would define the environment (usually with a virtual machine image or provisioning scripts) in which the programs run. Any change required in the environment needs to be communicated to the Ops team by the developers. Communication between two groups often leads to miscommunication, in this case increasing drift between the environments setup by Ops and developers. Such a drift will prove costly when things fail in production.

Containers solve this problem rather elegantly. It shifts left the step of defining the environment from the Ops to the developers. Developers now define the container themselves and pass on the code along with its environment to the Ops team. There is no possibility of environment drift since both Ops and developers are running code on the same environment. Finally, this results in a tighter feedback loop that is less prone to issues while remaining cheap.

The “shift left” practice is a direct outcome of adopting a mindset that focusses on faster, tighter and cheaper feedback loops. Such a mindset will allow you to discover opportunities to make your creative process more efficient and fruitful.