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.
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.
Please share your thoughts and feedback @teamcodestream.
New Relic CodeStream integrates all of your essential dev tools, such as GitHub, GitLab, Bitbucket, Slack, Teams, Jira, Trello and more, into VS Code, Visual Studio, and any JetBrains IDE.
During our daily stand-ups we demo features in development to allow everyone, which now includes you too, to stay in the loop and provide early feedback.