Introduction
In my previous blog post, we discussed the state of the union for shift left and how many organizations are not implementing it correctly. So what now? We need to understand the are signs of doing shift left incorrectly and learn how to take a different approach.
Recognizing the consequences of a poor shift left model
A poor shift left model has “soft” and “hard” consequences. Soft consequences impact the development staff’s workload, health, and job satisfaction. Some of the soft consequences of a poorly implemented shift left model include:
- Increased workloads
- Burnout and mental well-being
- Reduced productivity
- Poor job satisfaction
Hard consequences are those that impact the actual business. Some of the hard consequences include:
- Delays in shipping code/applications
- Lower-quality tooling and automation
- Increased security risks
- Increased likelihood of outages
- Poor customer satisfaction
Many of the high friction points with a poor shift left model involve developers’ interaction with things like security, infrastructure, and observability and their having to understand complex security protocols, threats, and tools. Developers may have to interact with physical or virtual infrastructure. Also, having to instrument tracing, metrics, and logging for applications are a few of the many shift-left-oriented areas that cause toil for developers.
In addition to the technologies, developers must deal with the time it takes to learn new processes, adopt new tools, and interact with new groups.
Smart shift left – the steps to a better way
In addition to providing developers with a streamlined way of learning about the new things they must take care of, there are other practical steps to ease the burden of shift left.
Go to the developers
Developers have many tools, technologies, frameworks, SDKs, and communication tools to deal with. So, go to where they are and provide them with value through learning, services, and processes.
- Provide value in the developer tools: High-quality IDE plugins, well-documented and well-implemented automation frameworks, well-supported SDKs, etc.
- Engage with the developer community where they are: Educate and enable them at hackathons, dev-centric events, and inside dev-centric forums.
- Reduce/remove the developer toil: Cross-environment tooling, in-code API and image checks, reliable API documentation (changelogs, roadmaps, etc.).
Maintain consistency inside of tooling
Once developers check in code to a CI/CD pipeline, provide the configurations and integrations in the pipeline that keeps things from falling apart.
- Maintain consistency, security, observability, and quality inside of the pipeline
- Add additional capabilities to do external API security checks and infrastructure dependency checks
- Add pipeline observability into the end-to-end observability architecture
- When safe and wise to do so, add in AI/ML capabilities to augment code quality checks and remediation
Derive value from the experience
Provide end-to-end value for the developer, operations teams, and business leaders.
• Maintain end-to-end observability for both technical and business insights
• Conditionally add policy triggers to the insights so that semi-automated or fully automated actions are taken
• Leverage multi-persona dashboards: Use the same tools, but the view changes for each persona
• Circular improvement: Value or loss of value finds its way back to the left for retrospective and improvements
What is Cisco doing in this space?
Cisco DevNet and the product engineering teams provide developer-centric training, tools, and code to reduce the toil in programmatically interacting with Cisco products and services.
- Access to Infrastructure-as-Code, API and SDK documentation, tools, and code
- Developer and operator learning
- Secure Application Integrations such as Panoptica’s API Gateway integration
- Secure CI/CD pipeline integration via Panoptica’s CI/CD integration
- Access to live interactive test environments for developers and operators to build and test their automation code, such as the NSO Developer Explorer and NSO Developer Studio
- End-to-end observability for code, applications, and infrastructure via Cisco Full Stack Observability
Achieving a balanced approach to shift left
While shift left is fundamentally sound and beneficial, it has been stretched beyond its original intent and misused, negatively impacting developers and product quality. The focus must align towards improving quality, security, and availability by catching issues early – without overburdening our developers or compromising the product’s integrity. You can accomplish this by enabling developers with the training, tools, technologies, and processes.
A balanced approach, incorporating the core principles of shift left without overextending its reach or misusing it to cut corners, will help organizations achieve their goals.
As we continue to navigate the evolving landscape of software development, we must remember that methodologies and frameworks are there to facilitate our work, not to hinder it. And like any tool, they are only as effective as the hands that wield them.
