How Left Can You Shift?
Now I’m not sure what you’re thinking coming into this text, dear reader, but I’d like to let you know straight away that shifting left isn’t about the welfare state. At least not in this article.
With that out of the way, what does shift left mean in software development?
Kirstie Magowan defines it rather elegantly in her blog:
Shift left is a practice intended to find and prevent defects early in the software delivery process.
Although this pretty much nails it, I’d like to extend the definition a tiny bit and say that shift left is the practice of getting faster feedback about your work. It’s not just about defects.
So how do we do this?
Let’s look at a few areas where we can apply this practice.
Code review
I’ve long been a very vocal and avid supporter of code reviews. I maintain that you should commit small changes to source control and have them reviewed as you go.
So, this shifts code review left. But we can do better. Much better.
Although the code review process is incredibly valuable, it’s not a very efficient process. When presented with a large amount of code, we tend to skim it, rather than review it, or as Giray Özil nicely put it:
Ask a programmer to review 10 lines of code, he’ll find 10 issues. Ask him to do 500 lines and he’ll say it looks good.
The conversation might look something like this:
Tech lead: “So… does it work?”
Developer: “Yep.”
Tech lead: “Well… I guess it’s ok. We’ll fix it later.”
No. You won’t. Let’s fix it now.
How? Try pair programming.
You can take turns with your teammates and get immediate feedback on business logic, error checking (best done on someone else’s chessboard, isn’t it?), code style and even IDE use — God knows I’ve learned the best IDE tricks watching someone else type.
“Wait, wait… the thing that you just did — how did you do that?”
I’d even suggest making it mandatory. Your organization will be better off for it, and you’ll find most developers enjoy the experience. Especially now that so many of us are working remotely, the humanizing effect is immeasurable.
Quality
Have you ever realized somewhere along the way that your software has too many features to be reliably tested manually? I’ve found myself in this situation more times than I’d like to admit.
As it turns out huge manual regression suites aren’t a good quality control measure when faced with increasingly complex software. They’re not sustainable. Heck, they’re not even reliable! And who really wants to go through thousands of steps to check every nook and cranny to make sure the software still does what it’s supposed to?
So, yes, we must write automated tests. But which ones?
The Google testing pyramid says it all: write very few, very critical (but very robust!) end-to-end tests, a few more integration tests, and a metric ton of unit tests. How many? 10%, 20% and 70% respectively.
Yay unit tests!
So just write a ton of unit tests — case closed, right? Well… maybe.
Lately, I’ve been thinking that we may have been doing QA wrong all these years. Perhaps testing is the least important part a QA engineer’s job. But that’s a topic for another post.
Build and deploy
Do you or your developers occasionally merge something that breaks the build?
Sure, we should all build our code before we merge, and I’m sure that you do, dear reader. I, however, sometimes, in a hurry, forget my due diligence and I suspect there are a few others like me.
Rather than relying on developer discipline, I prefer automated pre-merge pipelines. That way whoever is looking at the pull request will be able to see that the code breaks the build before it’s merged. The pre-merge pipeline should use identical build scripts and configuration to production builds, and it should be checked in to source control.
Similarly, the deployment scripts and configuration should also be in source control and used for every environment that you deploy to.
To complete the trifecta, check the infrastructure configuration into source control and instantiate resources based on this configuration. This way environment provisioning also becomes testable and predictable.
Security
I see three straightforward ways to shift left on security: planning, education and automated testing.
Planning
Involve your security experts from the get-go. Tell them what you are planning to build and for whom, and which components and interfaces your system is likely to have. In return, they’ll be able to tell you early on about potential vulnerabilities and data protection issues, so that you can weave these into your user stories and architecture.
Education
Security risks and data protection should be an integral part of continuous learning for every developer. The more developers interact with these topics, the more it becomes a natural part of their thinking. Time should be set aside for courses and training.
Another way to teach security is with penetration test training. I’ve got great engagement when training this on our own software. There is something strangely fun about trying to break the very thing that you’ve built.
Automated Testing
Finally, when the code is in, you should run automated security tests. These can be custom made by your development, QA or security teams or provided by 3rd party tools like OWASP ZAP.
So how left can you shift?
As you can see shift left is not just about detecting defects, although it is the focal point of the practice. It’s about continually learning how you can do better from the start, up until the point where you can get it right the first time.
If you are not already doing most of these, you might be thinking: That’s a boatload — where should we start?
My recommendation? Start with pair programming. I can’t overstate the value of this practice. You get team building, learning, code review and quality work all in one package. I promise, you won’t regret it.
Next, a good CI/CD pipeline goes a long way. Put the automated checks and tests to work and declare a green build policy. It will prevent a lot of superfluous work.
The rest is up to you. All of these are important and all of them pay dividends, but some are less obvious to implement and depend somewhat on your team and company structure.
I wish you the best of luck on your journey!
Keep calm and shift left.
