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

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.

#articles #devops #shift left development #azure devops