Golden Paths Start with a Shift Left

The concept of “shifting left” is inextricably linked to modern application development practices and philosophies like test-driven development, golden paths and DevOps, and platform design principles like advanced automation, secure supply chains and GitOps. For the purpose of this article, we’ll define what “shift left” means as if we are explaining it to someone who knows nothing about the application development and delivery process.

In general, shift left means adding a task earlier in the process of making software. In app dev, that should mean achieving an outcome earlier in the process. Unfortunately, since making its way into the modern development vernacular, shifting left has often resulted in teams shifting decisions to developers. This might seem like a subtle distinction, but shifting the wrong things left can create real problems.

A crucial benefit to shifting outcomes left is that it helps preserve developer productivity. Productivity is enhanced when developers are able to work in a flow state. Mental context switching is the bane of many a developer’s existence, and it becomes an unwelcome interruption when developers are forced to make decisions and handoffs in the middle of their workflow. Not only does context switching add cognitive burden, more importantly, it disrupts developers’ state of flow, something that anyone practicing a craft — and writing code is a craft — covets and cherishes.

Over the years, “shift left” has become a rallying cry for incorporating (usually) security into the application development and delivery process earlier. But security isn’t the only area where shifting left has potential benefits. In fact, one could say test-driven development is one of the earliest expressions of shifting left as it ensures that code is tested throughout the process. So a developer does not have to send their code to be tested after spending days, weeks or months writing it. Testing becomes part of the flow.

So what do we mean when we say shifting left is about outcomes? Well, let’s take security again because right now that’s still the most popular use of the shift-left model. Though a worthy outcome, security as an outcome is too broad and all-encompassing to be practical. Breaking down something like security into specific or more discrete outcomes is a more practical and sustainable approach.

Security isn’t the only area where shifting left has potential benefits.

As an example, a secure software supply chain is a specific outcome and, by its nature, is meant to enable developer flow and a better developer experience. An attack targeted deep in a software supply chain along the lines of the Solar Winds hack can render a CVE undetectable by a security scan conducted at the end of a process/loop. However, if supply chain security is the outcome, we might implement hermetically sealed builds. It’s important that app dev platforms and tools should not burden developers. Ideally, your platform lets you enforce policies without hindering innovation.

Vulnerability awareness is another distinct outcome from security. For vulnerability awareness to be useful, it needs to be separated from security enforcement. While this might seem counterintuitive (why wouldn’t you want to deal with the problem right away?), it ultimately preserves mental context. When we shift awareness left, we are letting the developer know that their code is running afoul of a stated policy and will not get through the next gate. It does not stop the developer in their tracks to enforce the policy, which could cover anything from which container image version to use to a minimum number of days from the last image scan.

Another example of separating awareness from enforcement is the case of a new CVE that doesn’t have a fix. While security teams work on the fix, development teams can continue working on writing their code until a fix is available and they have to implement it. We know that mental context switching comes at a cost to productivity and happiness, and by separating awareness from enforcement, developers can preserve that context and, ultimately, their productivity.

Along that same vein, let’s look at application performance or vulnerability data. We might say that we are shifting observability left, but observability is not an outcome. Actionable application data is the outcome and lightweight observability at the app layer is how we are able to shift it left. Unlike what we might think of when we talk about observability writ large, app layer observability gives developers a quick view of how their app is performing and helps pinpoint issues so they can go in — at their own convenience — and deal with the issue.

Leading with outcomes when shifting left can preserve developer flow, smooth the path to production, bolster security and unleash innovation.

Another outcome that can and should happen much earlier in the dev process is API scoring and validation, which is critical for any team that considers itself API-first. In this case, we can see how engineers and developers can have their API scored or validated before they write their first line of code. By leaving the scoring and validation to the end, a team may have spent many cycles designing and building the API only to have it rejected at the registration process. It’s much more productive if the developers and development teams already know their organizations’ must-haves for API design at the beginning of the process.

These are just early examples of how leading with outcomes when shifting left can better preserve developer flow, smooth the path to production, bolster your security posture and unleash innovation.

At the onset of this article, I mentioned golden paths and I’d like to close with them as well. Since Spotify introduced the idea in 2020, golden paths have gained a lot of attention among platform engineering teams, line of business leaders and app development teams alike because they reduce friction in developers’ path to production. At their most basic, golden paths give developers a streamlined path to production that is blessed by their infrastructure and operations, security and platform engineering teams. Golden paths must adhere to shift-left principles if they are to be effective.

However, they should represent the culmination of trust in decisions and processes, not just for the teams that create them, but also for the developers who use them. And organizations that focus on shifting outcomes left, thoughtfully and responsibly, will be the ones that design a golden path that works for everyone.