“Shift-left”: Pitfalls and how to avoid them

App developers play a critical role in making sure that businesses succeed and stay competitive. But the “shift-left” philosophy that has come to dominate thinking about DevOps (or rather, DevSecOps) has had the effect of leaving them overworked, stressed out, and tired of being blamed for every issue or vulnerability that appears upon deployment of the apps organizations depend on. 

Especially now, when developer talent is getting harder to find, the employee churn and loss of productivity that results from burned-out developers is terrifically costly. Fortunately, this is a problem that can be fixed.

What is shift-left?

In the olden days, developers coded apps, and then the QA engineers would vet the apps for functionality and ease of use, and then security teams would check them for vulnerabilities. And only after everything is checked out would the apps be deployed for operational use.

No one has that kind of time anymore. We need those apps operational now now now! The solution was, and is, shift-left, which refers to moving QA and security leftward in the (formerly) linear software development lifecycle (SDLC). QA and security would henceforth be dealt with during the initial development of the app, or even in the design phase. 

Theory vs. practice

A fine idea in principle. In principle, it meant that QA engineers, security experts, and developers would work together throughout the SDLC, collaborating in real-time to dramatically accelerate the process and get apps deployed sooner.

In practice, however, this approach all too often means that dev teams are held responsible for things that are outside their area of expertise. Cultural issues make it more challenging than expected to achieve that level of collaboration, and developers have in many cases been given the QA and security tasks on top of their basic job description. 

Of course, there’s nothing wrong with asking developers to think seriously about security from the get-go. If they can identify a potential vulnerability in the design phase, then it can be fixed easily. Whereas if it only comes to light after the app has been coded and compiled, then it might be a much more time-consuming process to fix it, especially if the vulnerable code has dependencies coded in as well. 

As Shannon McFarland explains in this Cisco blog post, the projected benefits of shift-left are significant: 

1. Enhanced collaboration, as QA, security, and dev teams work together and all of them improve their understanding of the whole SDLC process
2. Reduced costs thanks to identifying and fixing issues earlier in the process, meaning faster and easier
3. Increased security as developers learn to integrate security into the design process
4. Improved software quality as fewer quality issues are likely to survive operational deployment

But in the place of these benefits, too often the results are:

1. Increased workload as developers take on new tasks for which they are not trained, with no reduction in their existing workload
2. Continuous learning as developers is required to constantly master new tools, processes, and technologies as more things get moved earlier in the development lifecycle
3. Burnout, as developers find themselves under increasing pressure to create secure, high-quality apps even faster than before
4. Disrupted team dynamics as traditional organizational boundaries are blurred. 

From linear to continuous

As Melinda Marks argues in this TechTarget article, part of the problem with shift-left is that it is based on a traditional, linear understanding of the SDLC. But today’s cloud-based dev processes are dominated by continuous integration/continuous delivery (CI/CD) pipelines. 

To put it much too simply, this means that new functions and features—new branches of a constantly growing codebase—are continuously being developed, deployed, and integrated into existing apps. There is no moment when the app is finished, stamped “APPROVED” by both QA and security teams and deployed to go out and do good in the world. Business-critical apps are always in an ongoing state of becoming.

This makes it much harder to point to a spot along a linear process and say “Now we’ll do QA here, instead of later.” And it means that developers, QA engineers, and security specialists are all plying their crafts at the same time, in a continuous loop of innovation and improvement.

Making it work

Leadership, clearly defined responsibilities, a blameless culture, and buy-in from all stakeholders are the keys to a successful shift-left strategy that gets the benefits without the downsides of developer exhaustion and all the costs that entails.

This requires hard organizational skills, like being able to design a process that specifically delineates each team’s responsibilities, rather than just saying that developers have to do more QA testing and security auditing. And it requires a lot of soft leadership skills, such as encouraging all stakeholders to participate in blameless post-mortems, teaching everyone to both take and give constructive criticism graciously, and managing the integration and collaboration of teams that traditionally have operated in separate silos.