Software engineers are constantly moving jobs, and part of that has to do with the fact that they’re being tasked with meeting unrealistic expectations for both software delivery speed and quality. Learn how shift-right testing and AI-powered CI/CD are empowering developers to release faster while also improving software quality. Plus, in the process, they boost job satisfaction as well.
Introduction: Software Developers Are Being Pulled In Two Different Directions
Why do software engineers move to new jobs so frequently? There are no doubt lots of reasons, such as the fact that development skills are in high demand, which makes it easy for developers to move around in their careers.
But another important part of the answer is surely that developers in “modern” organizations often feel like they are (to employ an overused saying) wedged between a rock and a hard place. On the one hand, they’re told that they need to produce code fast, and then find ways to produce it even faster. That’s what continuous delivery is all about. On the other hand, they face ever-increasing pressure to improve software testing and rigorously ensure that code meets quality assurance expectations before it’s deployed.
If you tell developers to code faster and code more carefully, you are pulling them in opposite directions—unless, that is, you supply them with the tools they need to reconcile both goals and achieve them in tandem.
With the help of new delivery techniques, like shift-right testing, and new technologies, like AI-powered CI/CD, it is becoming easier to empower developers to release faster while also improving software quality.
Here’s a look at what it takes to square this circle, and why this is so important for developer job satisfaction.
A Day in the Life of a Typical CI/CD Developer
To understand why the contradictory demands that developers face can make their jobs so frustrating, let’s walk through what a release cycle looks like for a typical developer.
The cycle starts with the developer writing some code, then checking it into a codebase. That’s easy enough.
Things get harder when it comes time to test the code. The developer has to write test cases if they don’t already exist. That usually doesn’t take too long—maybe ten or twenty minutes for a basic setup—but it’s still manual effort. Most developers would rather spend their time writing application code instead of writing tests for application code.
Then, the tests are run. Results usually come back pretty quickly, especially if tests are fully automated. But if something fails—and it almost always does on the first several runs—the developer has to figure out why, fix the code (or the test itself, if that caused the issue), and retest. On average, it might take a half-dozen repeats of this process before all tests pass. Only then can the code finally be cleared to deploy, and the developer can finally get back to what he or she does best—writing code, as opposed to testing code.
If this is what your development routine looks like, it can easily take days to get a new release out the door. And if you have a large development team with many different people needing to write and test code for each release, it could take weeks before everything passes and you can deploy.
Now, this might not be so bad if the only expectation placed on developers was to test code thoroughly—if we were still living in the age of Fred Brooks and “cathedral-style” software development, when no one complained if it took years for you to make a new release.
But those days have been superseded by the age of continuous delivery. In the eyes of the people who tell developers what to do, releasing app updates early and often is just as important—maybe even more important—as maintaining software quality. That’s the only way to stay ahead of the competition—or so developers are told by bosses, who frequently like to point out that Netflix does thousands of deploys per day, so they should, too.
Faced with these competing pressures, it’s easy to understand why so many developers walk off the job after a few years. They become frustrated and move on in the hope of finding something better—which is hard because the type of cross-purpose expectations described above apply at most organizations that have embraced “digital transformation” or jumped on the DevOps bandwagon in one way or another.
Make Developers Happy Again by Making Testing Smoother
One way to avoid this conundrum would be to abandon the ideal of continuous delivery and go back to the days of slow-but-steady waterfall releases. Then, you could test to your heart’s content without worrying about how slowly you are releasing. But you’d also miss out on the very real benefits of continuous delivery.
Fortunately, there’s an alternative solution: speeding software testing cycles in order to free developers to deploy code almost as quickly as they write it.
Achieving this goal requires a mix of innovative strategies and tools. One is shift-right testing, a method that allows developers to move some tests to post-production. While there are some obvious risks in doing this if it means leaving critical functionality untested until after it is deployed, it is an effective method of speeding the pre-deploy feedback cycle. And the risks can be minimized if you focus on shift-right testing for non-critical features that aren’t going to spell total disaster if they do creep into production.
A second strategy is to leverage AI and machine learning to improve software tests. By parsing data from past tests and production environments, AI tools can identify which components of an application are the most sensitive or the most likely to fail. This not only removes the guesswork from writing test cases, but also helps prevent situations where no one thinks to test a critical issue until just before deployment, forcing testing back to square one.
Strategies like automated and blue-green deployment can enable faster feedback cycles, too, by allowing developers to take more risks (and, by extension, run fewer tests) while still enjoying the confidence that they can roll back to a known-good release quickly if something goes critically wrong.
When developers are allowed to use techniques like these, everyone wins. Users get faster updates. Managers, too, see faster innovation and can rest easy in the knowledge that their developers are keeping up with the CD-obsessed Joneses. But most importantly, developers themselves are happier because testing no longer hampers their ability to release code as quickly as they can write it.