How to Prevent Shift-Left Approach From Making Developers' Jobs Harder

On the surface, the shift-left approach — which encourages DevOps teams to begin processes such as testing and security as early in the software development lifecycle (SDLC) as possible — may seem like a boon to developers. Theoretically, shift-left saves developers time and effort by reducing the amount of work they need to perform later in the SDLC.

But viewed from another angle, shift-left is a threat to developers. Even when teams implement shift-left processes with the best of intentions, their initiative can have the perverse effect of making developers' jobs harder, not easier.

This is not to say that the shift-left approach is a bad idea and that no one should do it. But it is to say that there are potential downsides to shift-left development strategies — especially for developers — and it's important to consider those problems before shifting everything in your SDLC left and proclaiming your team a champion of modern development best practices.

What Is Shift-Left?

Shift-left is the practice of starting various types of software development processes earlier in the software development lifecycle than when those processes have traditionally begun.

For example, if you shift security left, you make security a priority starting with when code is designed, rather than waiting until after an entire application has been built to begin addressing security risks.

Related:Do Programmers Still Need to Have Linux Skills?

Likewise, if you shift software testing left, you begin testing software for quality and performance requirements as soon as you write code — as opposed to running tests just prior to deploying the application into production, which is the more conventional approach.

Shift-Left Benefits: Theory

In theory, shift-left is beneficial because it allows teams to detect problems earlier in the SDLC. That's valuable because, in general, problems are easier to fix when you find them early.

For example, if developers identify an input validation risk within newly written source code, they can simply update the source code to fix the problem. Remediating this type of issue would be much harder if the problem remained undetected until the source code had already been built and other code had been written that depends on the problematic source code. In that case, developers would potentially have to make more expansive changes to their code to fix the problem. They'd also have to recompile the code after making those changes.

The shift-left approach also offers the benefit of increasing the chances of detecting problems before buggy or insecure code reaches end users. The earlier you begin validating your code, the lower the risk that you'll deploy it before finding problems.

Related:What Is Ubuntu?

Shift-Left Benefits: Reality

It's certainly true that, in general, shifting processes left saves money and reduces the risk of introducing serious software problems into production environments.

On the other hand, there is a large potential disadvantage of shift-left practices: They increase the burden placed upon developers because they require developers to participate in workflows that would traditionally have fallen to other types of engineers.

For instance, performance testing is a job that has conventionally fallen to quality assurance (QA) engineers. Developers handed code off to the QA team, and the QA team tested it. But if an organization wants to shift performance testing left by running tests on code as soon as the code is written, it either has to require developers to run those tests or find a way to embed QA engineers within development teams so that the QA engineers can run tests whenever new code emerges. Either way, developers end up having to do more work.

The same goes for shift-left security. While it's certainly not a bad thing to ask developers to think about security in the early stages of the SDLC, shift-left security can turn into a strategy wherein developers are expected to become experts in security testing and optimization — expertise that falls outside the scope of the conventional developer's skill set.

A second problem is that taking a shift-left approach means that developers are more likely to end up in the line of fire when something goes wrong. If you ask developers to become QA and security engineers in addition to developers, it becomes easier for actual QA engineers and security engineers to blame their organization's developers for performance or security problems.

That's a departure from conventional approaches, wherein developers might have been asked to address problems whose root causes were tied to code they wrote, but they didn't face as much pressure to perfect their code from the start because they weren't expected to be experts in domains that extend beyond development.

When You Shift Left, Remember the Developers!

None of the above means that shifting processes left is an inherently bad idea. Shift-left does offer real benefits.

But it also poses a certain amount of risk to developers, and too many conversations about shift-left ignore those risks. Organizations that want to shift left effectively need to think about the added burden that shifting left places upon their development teams and take steps to ensure that shifting left doesn't end up creating more work for developers than it saves.

They can do this by specifically defining how they shift processes left. Too often, shift-left initiatives are vaguely defined, leading to situations where there are no limits on what developers can be asked to do to advance the shift-left agenda. Instead of making shift-left an open-ended process, teams should create plans that say, "Developers will do A, B, and C, and QA engineers will handle X, Y, and Z," for example.

It's also important to make sure that blameless culture goes hand-in-hand with shift-left initiatives. In a blameless culture, the team as a whole shares collective responsibility for problems. Blameless culture reduces the risk of fingers being pointed at developers alone when the team makes mistakes.

Ultimately, shift-left should save developers — along with everyone else — time and effort while also facilitating the creation of better software. But that only happens when teams work to ensure that shift-left doesn't become a drain on developer productivity.