In the early 2000s the concept of “shift left” was introduced and rapidly adopted as a way to improve source code quality and security by moving testing earlier in the software development lifecycle (SDLC). Around the same time, test driven development (TDD) became a widely accepted best practice and further emphasized early testing by requiring devs to write unit tests before a single line of code was written.

By the 2010s the role of “test” in software development was changing to focus on higher level quality oversight, or in some cases was split between development teams and operations as DevOps processes became popular. Today we’re looking at the latest SDLC process improvement concept for the 2020s - shift down - and how you can leverage it to empower your DevOps team and make it even easier for them to maintain high quality standards.

Benefits and Limitations of the Shift Left Approach

Shift Left is a concept based on a left to right view of the phases in the SDLC. Testing was traditionally last on the continuum, or farthest to the right, and shift left brought testing into earlier stages of requirements gathering, design, and coding. Everyone in each phase of the SLDC was expected to look at their areas with a more critical lens, testing on their own where possible, and consulting with testers earlier in the process to identify potential future issues so adjustments could be made to prevent them.

According to the IBM Systems Sciences Institute in 2010, a bug found in testing costs 15 times as much to fix compared to if it is found during the design phase. Finding a bug in the coding phase, while not as beneficial as catching it during design, will still save 6.5 times the cost. Given these statistics, it’s no wonder companies in the 2010s were eager to take shift left testing even more seriously and modify their testing best practices to improve their products earlier while cutting costs.

The biggest limitation of the shift left approach was the concept of the SDLC on a linear continuum. As companies shifted to more iterative development and microservices, the shift left software development concept did not always align. Large, complex products create dependent feature chains that can be difficult to test efficiently early on in development, especially if the team is releasing more frequent, smaller changes.

Microservices can be hard to test early on because the services are often interdependent and testing them in isolation or without completed integrations has limited value. In addition, one of the biggest benefits of iterative development is that small, frequent changes enable feedback from customers that developers can respond to quickly. Shift left strategy does not focus heavily on this post-release feedback cycle because it is to the right of testing, but customer experiences often yield a wealth of product improvement suggestions.

How DevOps Embraces Shift Right and Shift Left Methodologies

DevOps brings together the people, process, and technology of the development and operations portions of the SLDC. Rather than working in a linear continuum, the development team partners closely with operations in a continuous improvement model often represented with the infinity symbol.

On the dev side the team can still leverage shift left testing techniques to ensure quality by detecting security vulnerabilities early, but frequent releases allow the operations team to shift right and monitor customer feedback and communicate bugs back to the dev team quickly. Getting real-world feedback helps uncover bugs that are hard to simulate in test environments and gives teams the ability to utilize techniques like A/B testing to make feature decisions based on data from customers using the product.

How traditional testing fits into DevOps, however, varies across companies. Many have shifted testing activities to the devs, embracing unit testing and “you build it, you run it” to its fullest. When combined with large code bases and often disjointed tools, frameworks, and methodologies, the learning curve for joining a new dev team can be steep and the cognitive load of learning systems and processes beyond just writing code seems disproportionate.

Shift Down to Ease the Cognitive Load on Developers

While the DevOps approach to rapid testing and release can increase a developer’s workload, mature DevOps platforms can also reduce the cognitive load on devs by shifting down to the platform. Shift down is about simplifying and compressing your tech stack and investing in platform engineering resources to support your DevOps platform as its own product. This sounds like a relatively simple switch to make given the popularity of DevOps processes, but it is actually a cultural mindshift that can require some tough choices about what to keep and what to eliminate.

Optimizing your tech stack begins with identifying areas of redundancy and gaps. Offering multiple tools that accomplish the same tasks increases the learning burden on developers and makes it more difficult for devs to switch from one team to another and hit the ground running. As much as we have automated to improve efficiency, sometimes there are still gaps in our processes. If you haven’t already, identify areas of manual work and find technologies to fill those gaps.

Interoperability and integration are other items to consider when choosing which tools to keep. A set of DevOps technologies that work together under a unified or closely connected platform will make it easier for devs to move from one task to another. Google offers a suite of tools as well as ongoing education and insights from its DevOps Research and Assessment (DORA) team.

Microsoft’s Azure DevOps is a tightly integrated suite of tools that work with GitHub and Visual Studio. Atlassian has OpenDevOps that integrates like Jira along with industry leading partner tools. GitLab puts an extra emphasis on security with its DevSecOps Platform offering. AWS offers some solutions of its own, but also has a robust partner program that provides strong integration with partners that have their own areas of expertise in DevOps on AWS.

Many of these companies offer broad solutions but also allow you to customize your solution to use only the pieces you need. This gives teams the flexibility to pick and choose which components work best for their workflows and use a combination of in house tooling supplemented by outside solutions.

As you can see, there are many options when it comes to DevOps. This can be both powerful and overwhelming, making the concept of shift down even more important. Evaluate your processes and identify the minimum tool sets needed to make your team effective and efficient, then work to transition everyone to your new engineering platform through robust training and self-service documentation.

Use Pieces to Enhance Collaboration

As part of your shift down to the platform, use Pieces to encourage knowledge sharing and internal documentation. Your DevOps team can use Pieces to share code snippets, screenshots, and workflow contexts and the built-in ML powered enrichment adds descriptions, tags, documentation links, and more to make sharing and finding resources even easier. You can also leverage a variety of extensions and plugins to integrate Pieces into your workflow using your existing tools.

With support for multiple LLM runtimes, Pieces Copilot is a powerful productivity tool that can be customized to fit the needs of your team. The Pieces Copilot runs at the OS level so it can learn your end-to-end workflow and offer contextualized suggestions across your existing toolset. Shift down to the platform without sacrificing cutting edge AI technology with Pieces Copilot.

Conclusion

Our approach to the SDLC continues to evolve as companies look for efficiencies without sacrificing quality and security. The DevOps model provides a way to balance shifting left and shift left testing practices, but has not yet fully addressed the increased cognitive load some of these practices place on developers.

Shift down emphasizes platform engineering and compressing tech stacks to reduce cognitive burden. With Pieces, your team can share code snippets and documentation within existing workflows - prevent context switching while preserving important context-specific information through ML generated tags and metadata. By leveraging solutions with integrated features and workflows and eliminating redundant tools, developers can rely on engineering platform teams to maintain DevOps platforms and focus on coding.