(missed) Shift Left
Shift left! Shift left! They say. This is a common refrain when people are talking about DevOps. Deming taught that we have to build quality in, we cannot inspect quality in at the end, so we need to shift left.
So teams set off to shift left, not sure exactly what this means, but often it’s approached as though it will mean more of their work will be given to the developers. They will finally understand what we go through! They will finally learn about our jobs!
- Operations folks believe this means that the developers will become experts in infrastructure and will be on call for every outage.
- Security folks think this means that developers will have to keep in mind every XSS, CSRF, SQLi and any other vulnerability possible while still writing high quality code.
Shifting left does not mean that other people do our jobs. We still have to do our jobs and the developers still have to deliver business logic for the customers.
Shifting left means making it easy and safe to do things earlier in the process.
The Platform
Back in the early days of Infrastructure as Code (IaC), we spent a lot of time trying to figure out who would be writing infrastructure code. The Ops folks didn’t have a lot of experience writing code, and the developers probably needed to understand the infrastructure. So we would demand that developers needed to learn our tools, and our jobs, so that we could deploy their code and infrastructure.
Except that’s not shifting left. That’s making the developers do our work. With the rise of platform teams as highlighted by Team Topologies , we can see that we need to provide a way for developers to deploy on infrastructure, without being concerned with all the details (IAM, security groups, routing, etc), while still having the ability to do it themselves (easy) and without much opportunity to break things (safe). That doesn’t mean they need to learn CloudFormation.
I once worked with a very high performing software development team that had deployed their own infrastructure before they’d hired any Ops folks. They spent the bare minimum of time on the infra because their job was shipping software, not worrying about network interfaces. When we shifted left, they could easily and safely deploy the necessary infrastructure to build their services, and they didn’t need to write infrastructure code!
We don’t want to do it either
I was working with a client whose Ops team felt it was toil to create the user accounts in Gitlab for all the different development teams and manage all the group assignments, new hires, departures, etc. They decided that they would shift left and give permission (and detailed instructions) to the development managers about all the steps required. Empowerment!
The response from the development managers was fairly predictable.
- We can see why you don’t want to have to do this.
- We don’t want to do your job for you, we already have our own concerns.
The Ops team was simultaneously furious and disheartened. They’d thought the managers would be grateful. They only realized after the fact that this wasn’t eliminating toil, this was distributing toil to the edge!
To truly shift left, we discussed when user accounts were created, and where. It turns out that they had an Active Directory setup and GitLab even has an LDAP integration! Sure, there would be configuration needed and probably some glue code to be written to get everything setup properly, but now user management for those users would be essentially automatic. As we say in Agile: maximize the work not done!
Really shifting left
In order to really shift left, we need to enable people to achieve their objectives safely and early, without needing to have your expertise in addition to the expertise they were hired for. It’s not just moving the work earlier in the process.
There are lots of different groups that can empower developers to work quickly and safely.
- Infrastructure
- Security
- Quality Engineering
- Marketing
- Etc.
How you help the whole organization safely and easily ship higher quality software is up to you.