How Far Left Can You Shift?

Introduction

The impetus behind shifting left has always been to catch problems earlier, before they become painful and expensive to solve.

In his article, The Shift Left Principle and DevOps IBM’s Rick Weaver explains how it’s supposed to work, and why it’s important to shift left: “The premise behind ‘Shift Left’ is that we move things that we typically do in later stages earlier. It is human nature, but many people tend to defer particularly tough issues. […] Ultimately this leads to significant problems when we eventually try to address the issue. The graphic below illustrates what happens. It’s also an indicator that more agile approaches are needed.”

As the image below indicates, the Shift Left Principle is intended to shorten the time between the identification of an issue and its resolution.

SEE ALSO: “The priority going forward is making automation actionable, scalable and intelligent”

Image Credit: DevOps Zone

Note that the chart does not explicitly refer to DevOps, but rather to Development Progress. So why is it that DevOps gets all the action when it comes to shifting left?

The Broken Developer Collaboration Process

The typical development workflow begins with assigning tickets or tasks to developers. The developer often spends enough time on any given assignment to get the feature built or the problem solved before declaring that it’s ready to be reviewed by pushing the code and creating a pull request or merge request.

Often, that is the first time when feedback is provided in the form of a code review, which as often as not, means it happens too late. Assuming the developer had questions along the way, she would have typically asked someone in her office for input, or she could have copied and pasted the code in question into Slack or an email and explained what she was trying to figure out.

These informal approaches do not move the process to the left. In the case of asking someone in the office (it’s very hard to imagine that happening today during the COVID-19 pandemic) there is no record of the exchange. In the case of copying and pasting into Slack, the process is so tedious (because you have to explain the context you just lost by moving away from your IDE) that it does not happen often.

When it does, the exchange is then lost in a Slack stream never to be seen again, completely disconnected from the code itself, and represents a lost opportunity to meaningfully share knowledge with the team.

Shift Left Development

To shift left in software development means to pay attention to the quality of the code earlier. While DevOps has been moving upstream successfully, and companies specializing in CI/CD have become prominent, the iteration and attention needed to improve quality as early as possible requires a different approach entirely on the part of the development team.

Image Credit: Devopedia

As described by Devopedia, “The principle of Shift Left is to take a task that’s traditionally done at a later stage of the process and perform that task at earlier stages … shift-left is less about problem detection and more about problem prevention.

Shift Left doesn’t mean “shifting” the position of a task within a process flow. It also doesn’t imply that no testing is done just before a release. It should be seen as “spreading” the task and its concerns to all stages of the process flow. It’s about continuous involvement and feedback. In addition to the process changes, Shift Left is also about the people.” That means better collaboration.

Benefits of Shift Left Development

When you adopt a Shift Left approach, and developers start discussing code as they are writing it rather than once they are finished writing it, you can identify potential problems or approaches when changes are both possible and not very painful.

This applies both to design and coding. As this is done with ample time to think it through, code quality improves and testing time is reduced. As a result, overall cost comes down. Further, by shifting Left, release dates become more reliable since it eliminates the crunch at the end of the process that often leads to delays.

In summary, better code, lower risk, reduced cost and less effort. So what does it take to implement a Shift Left approach?

SEE ALSO: Graduating out of maturity models

Implementing Shift Left Development

Beyond automation, collaboration plays a major role in shifting left. At CodeStream we have been working on reinventing code-centered collaboration. It starts with the ability to communicate about code without context switching. You can comment on and discuss at will any line or block of code and share that discussion with your whole team, both in their IDE, or on Slack, Microsoft Teams or email.

We recently introduced a Shift Left Code Review solution that allows any developer to request a code review with two clicks, right from their IDE. The review request can include any changed code based on the state of their repo. CodeStream will package all the changes up and let the developer choose the items to be included in the review, all the way from a local unsaved WIP to committed and pushed code. The reviewer gets notified via email, Slack or MS Teams and can then perform the review in their IDE with full source tree context.

Unlike web-based solutions like GitHub or GitLab, which only provide the reviewer a tiny snippet of the code that surrounds the changes, CodeStream Core Reviews provides you access to the entire source tree in the comfort and familiarity of their IDE, so there is no need to switch windows or break flow.

By enabling a code review on WIPs, and iterating around it, CodeStream makes Shift Left collaboration possible without requiring the team to retool. CodeStream integrates with all your favorite code hosts including GitHub, GitLab and Bitbucket, both cloud-based and on-prem.

It also integrates with most popular task managers and issue trackers such as Jira, Trello, Asana, Azure DevOps and GitHub Issues. For more details please vist our ProductHunt page or CodeStream.com.

The post How Far Left Can You Shift? appeared first on JAXenter.