Take the car manufacturing industry. Even though the industry is over 150 years old it has been barely 30 years since we can confidently buy a car knowing that the quality standards will be the same for every car of a brand, no matter where you buy it across the globe. That is because of one industrial revolution which took place in the late 80’s enabling the adoption of a zero defect approach to car manufacturing. Nowadays, car parts are continuously tested and optimized so that once put together, the final product works perfectly well and for a long time.
Well now let’s think how the software industry could benefit from a similar revolution. Seamless, bug free software at all times. Releasing high quality code with the velocity of a mature manufacturing industry. Well this could be possible if we were, just like for cars, thinking about software manufacturing with a zero defect approach and tooling ourselves for it.
Testing all components exhaustively, systematically and as early as possible in the manufacturing lifecycle. Systematically providing robust and viable software with optimized documentation, optimized factorisation, optimized test suite. It might be just ahead of us thanks to the latest technique in software development. Let’s review together one of the most promising software development methodology and a leading trend amongst best practice developers: the shift left approach.
Let’s start by getting everybody up to speed with a basic definition.
The shift left approach is a working methodology dedicated to optimizing the quality of your code while reducing the time and resources spent on bug fixing.
Basically producing high code quality with a “left” approach in order to reduce the amount of bug fixing you and your team do. What does left mean here? We’ll get back to it in a minute.
First let’s just answer one question. Why is it gaining momentum? Well the digitalisation of our economy is not losing speed. Quite the opposite actually. And for now the more you develop the more bugs to fix there is, so far the relationship between code production and bugs is proportional. The problem is: as there is more and more code production taking place, the cost of bad quality code is skyrocketing and we can easily predict that the software industry will not be economically capable of bearing this growing weight in the future. We need solutions to break the exponential relationship between bugs and developers
At the origin of the shift left approach lies one simple statistic. A bug - or should I rather say a code flaw - costs on average 80 US dollars if detected at an early stage of the development process [ ] In this scenario developers find it when they run their tests and correct it directly, it’s merely an interruption to the developer workflow. In the other case scenario they are detected at a later stage of the product development lifecycle. That could cost up to 7,600US dollars on average to fix : users reach out to support, support to QA, QA to developer, takes time, and more ressources and more time…. You can imagine how costs easily pill up.
So in order to ensure higher quality, developers identified that trying to detect bugs and flaws as early on in the development process was probably the best idea. In order to do that they needed to bring as many code quality tasks as early as possible in the development process. Starting with tests.
Indeed you might have noticed that most of the time shift left is followed by the word testing. That’s because the first and most obvious way to ensure code quality early on is to test early on. Are you keeping up with me? Maybe shift left testing will make more sense if we visualize it.
Here’s a graph of the software development lifecycle. The horizontal axis is the timeline between the very first step of software design and the moment when code is in production and the vertical axis is the cost of fixing bugs we have previously mentioned. 80 dollars if detected early, 7600 dollars if discovered late, right
So if we look at a standard lifecycle development we can see that most of the bugs are caught at the QA stage. The lower you test the more long (and expensive) bug fixing you’ll face because test did not enabled you anticipate them. You’ll be moving this wave to the right with an increase in zero days flaws
Well by shifting the code quality process to the left you get to put that debug cost under control, you deliver code with a much higher stability, you increase user satisfaction, you reduce the length and the width of task shifting when bugs are discovered and i let you find the other tangible and intangible benefits it has on the brand, on the team, on the process and for your end users….
Most of the time people underline the benefits of the shift left testing approach for cost control of software development because it gets businesses attention. The improved cost management is a result of optimizing how developers spend their time.
But, we, as the developer experience team at CircleCI, we are more interested in the fact that quickly identifying small flaws and fixing them early on is preferable to facing broken features later down the road for developers.
The shift left approach deserves much recognition when it comes to improving software engineers’ day-to-day. Spending more time fixing as-you-code is less mentally draining than the traditional late bug discovery lifecycle. Developers were used to being constantly interrupted in their workflow.
Having to constantly shift from the new project they were working on back to fixing issues on previously developed code is simply painful. The loss of efficiency and motivation that the traditional approach means for software engineers is unbearable.
Alright, I guess what you want to know at this point in time is why the shift left methodology isn't widely adopted yet? I
Well for the same reason testing is not widely adopted and QA processes are weak throughout most organizations. Lack of developers, lack of time, lack of appropriate tools, lack of knowledgeable leadership on these topics, overall lack of resources. We at the Developer Experience team of CircleCI are trying to make a humble contribution to the change: with our tools, with this learning hub. We are also learning in the process. This field is just starting to expand.
We don’t have all the answers yet but we are sure looking for them. For example: what do we know about initiating shift left development within a team. Shifting a whole team to the left isn’t easy:getting out of your comfort zone is always a leap of faith. Especially with deadlines and management pressure hanging over you.
Another question. How to implement shift left testing in your workflow? When you start shifting left you will have to deal with a big increase in early flaw detection and consequently an increase in time spent on writing and fixing unit tests. This can be overwhelming and you want to get all the need you can get to clear this pile of tests quickly. This is why the automation part of shifting left is key to your success. With a unit testing tool like the VS code extension we worked on, you can generate test files within seconds, avoiding the bottleneck effect.
In the shift left hub you will find many other resources to help you improve your coding journey. How to shift left code validation? What are the tools available? How does shift left code security work? How can someone shift left through better documentation or thanks to metrics? We will review all of these and more, feel free to explore the hub. You can also talk with our team and our community in our Slack or share with us on social media your ressources and best practices to improve your own developer journey. I’m very excited to see what you’ll share with us.
Welcome to the shift left hub