Shifting left is a simple, straightforward idea. Imagine a project timeline with a start date on the left and an end date on the right. Shifting left simply means moving a concern further left on that timeline so that attention is given to it earlier in the process. However, this often results in making the development team responsible for whatever is being shifted.

Having been a software developer in various industries for most of my career, I have a lot of empathy for the challenges that developers face. Today I’ll put on my Developer Advocate hat as we explore the idea of shifting left.

Why is shifting left important?

As Mark Eisenberg, Cloud Solutions Architect with Microsoft says, shifting left means that decisions and conversations about concerns like application architecture, data architecture, observability, and security are moved to the beginning of the process, where they can be trivially built in while they’re still on the whiteboard in the conference room.¹

Shifting left can have huge benefits for the security, maintainability, and longevity of a software project.

The Value of Failing Fast

Perhaps “Fail Early” would be more accurate. Concerns related to code quality, feature quality, security, and performance can require monumental efforts if left to the end of the project. Making adjustments and corrections early has a higher impact with less effort than trying to make them toward the end of the process when there’s more complexity to deal with.

Higher Quality Deliverables

Failing fast has the added benefit of producing a more stable product overall. As you continue to make adjustments and corrections each step of the way, you focus on ensuring that each component functions as intended and that all of the components of the system are integrated properly leading to a higher-quality deliverable.

Cost Benefits

Adjustments made earlier with smaller scopes are also less expensive than those made late in the delivery lifecycle, leading to more cost benefits.

Increased Talent

Lastly, we shouldn’t overlook the benefit to our delivery teams. In the early stages of their careers, developers typically focus on coding and learning the various frameworks and tools they need to be productive. Shifting things like testing, security, cloud infrastructure provisioning, and observability to the left puts these concerns closer to developers, allowing developers to be exposed to better practices and giving them a broader vision of the process and the product.

But companies don’t always benefit from shifting left. In order to reap the benefits, shifting left should be done carefully and with consideration. Understanding some common pitfalls can be helpful.

Recognizing and Avoiding Pitfalls

When vs. Who

The first pitfall is to assume that shifting left means making developers responsible for doing the work. In some cases, the developers will be the best candidates for doing the work, but that’s not always the case.

To avoid this pitfall, remember that shifting left is about when a concern is addressed, not who addresses it. Thinking “when” instead of who can help you consider how best to address the concern in your company.

If your best option is still to have the developers take responsibility, determine if what you’re shifting is already part of their skill set. If the work is completely new to them, look for developers who want to expand their skill sets and give them the training and tools to be successful.

Not Accounting for the Whole Effort

Shifting a concern to the left requires that its associated effort be accounted for earlier in the development lifecycle. This is especially important if the developers are handling the work since they’ll have to schedule it with their other work.

Also, candidates for shifting left don’t exist in isolation. Many of these candidates are first-class concerns that may have additional dependencies, and which require design, support, leadership, tooling, governance, etc. Shifting something left means those related concerns need to be accounted for earlier as well. Not accounting for these can be detrimental.

To avoid this pitfall, reassess effort estimates with the shift in mind. Account for discovery efforts that may be necessary if the concern being shifted is new to the team. If the shift has dependencies on other teams or business units, make sure they understand the adjusted timelines and secure the required support before making the shift.

Expertise

Some concerns being shifted require expertise. Giving the responsibility to teams or individuals that don’t have that expertise does provide a learning opportunity, but may result in poor initial implementations. It may be better to have someone with expertise work alongside the team instead of making the team members directly responsible.

To avoid this pitfall, consider the risk. For high-risk areas like security, substandard implementations could be detrimental to the business. If the concern being shifted is one that addresses major risks, ensure it’s being handled by people with expertise in that area.

Tooling

The last pitfalls we’ll discuss relate to tooling, and there are a couple of things to watch for.

It’s pretty common for companies to prescribe tools to be used for testing, code and security scans, etc. because it enables the company to benefit from economies of scale. In those cases, it’s important to provide training, pipelines, guidance, and other onramps that facilitate the adoption of the tool. Without these, adoption may suffer or be inconsistent with your objectives, and you may find teams neglecting it or finding ways to work around it. The result can be costly and in the end, you may find that the concern hasn’t shifted left at all.

Transition to Adoption

To avoid this pitfall, envision what a smooth transition would look like for teams adopting the tool. Or better yet, tell them the company is considering adopting the tool and ask them how best to ease their adoption of it. What pipelines and processes would need to be in place so that teams don’t think twice about adopting the tool? Make that vision a reality as much as possible to minimize the impact on the team.

Also, as great as tooling is, it needs to be configured to reflect and enforce the standards of your company and industry. For instance, a static analysis tool may have default settings for code quality, but if you don’t reconfigure those settings to meet your company standards, then your shift left hasn’t accomplished your objectives.

Clarify Your Objectives

To avoid this pitfall, remember that the outcome is the goal, not the tool. Clarify your objectives and the results you expect, then translate these into quality metrics. Inform your teams of these objectives and ask for input about appropriate tooling. Once a tool is selected, compare your company standards to the tool’s default settings and adjust the tool to match your requirements before making it a requirement for the teams.

If your organization doesn’t need to dictate which tools are used, simply make the desired outcomes and standards known and make it a requirement for delivery teams to demonstrate that they are meeting those standards.

If you’re struggling with concerns related to security, quality, data architecture, or observability in your deployed environments, you may benefit from shifting them to the left and addressing them earlier in your delivery process. Carefully considering how to shift left while avoiding common pitfalls can result in cost savings as well as software that is more secure, resilient, and maintainable.

[1] Episode 444 – Azure Innovations – YouTube