Author Peter Pickerill warns against the ‘Shove Left’ anti-pattern in DevOps, illustrating how offloading tasks onto developers without real change can harm teams and outcomes.

Summary of the Article

Peter Pickerill addresses a common pitfall in DevOps practices known as the “Shove Left” anti-pattern. While the “shift left” concept in DevOps encourages the early integration of testing, security, and quality controls within the development process, the “shove left” approach simply reallocates downstream tasks and responsibilities onto developers without proper system or process adjustments.

Main Points

  • Definition of ‘Shove Left’:
    • This occurs when organizations attempt to improve efficiency or security by delegating work previously done by specialized downstream teams directly onto developers, without equipping them with proper support, tools, or time.
  • Consequences:
    • Developers become overloaded, which leads to burnout and decreased productivity.
    • Inefficiencies increase as developers juggle responsibilities they may not be trained for or supported in.
    • The desired improvements in quality, security, or speed are rarely realized, potentially leading to project failure.
  • Underlying Issue:
    • The core problem with the “shove left” approach is that it focuses on reallocating tasks instead of improving collaboration and optimizing workflows across teams, often ignoring the need for systemic change.
  • Suggested Solution:
    • Organizations should embrace genuine “shift left” principles by fostering cross-functional collaboration, providing training, investing in effective tools, and evolving processes to support new responsibilities.
    • Sustainable improvements require proactive systemic changes rather than merely redistributing workloads.

Takeaway

Pickerill’s article serves as a cautionary message for organizations pursuing DevOps or DevSecOps transformations: meaningful improvement requires more than simply shuffling tasks. True success comes from holistic, collaborative, and well-supported changes that respect the capacity and expertise of developer teams.

This post appeared first on “DevOps Blog”. Read the entire article here