Shift Left 101 - Understanding the software development best practices
No matter where you first heard the term “shift left”, you must have heard it everywhere by now. Shift left has invaded the tech industry and an increasing number of engineers in the software industry are chanting these words, trying to make it the new normal.
We couldn’t talk about code quality, bugs and unit tests without giving you a quick recap of key elements to understand the shift left approach.
Once upon a time…
Poor quality software costs millions of dollars to the software industry and generates an ever-increasing number of additional fixing and maintenance costs. We’re not going to remind you of the list of risks you expose your business to: increase in development costs, loss of control over technical debt, branding erosion, rework effort, decline in team motivation, higher staff turnover…
With software engineers being such a scarce resource, the digitalisation of every layer of the market and the densification of software competition, it’s become an ever increasing priority to find new ways to develop software using less resources, at greater velocity. The shift left approach entered our lives in an attempt to solve this issue…
The shift left approach is a working methodology dedicated to optimising the quality of your code while reducing the time and resources spent on bug fixing.
It all started with an observation of the development lifecycle: several studies showed that the further down the development lifecycle you get, the more expensive bug fixing becomes.
Vulnerabilities would cost on average 80USD if detected at an early stage of the development process while they can cost 7,600USD and above to fix if they are detected at a later stage of the product development lifecycle.
The obvious output of this is that identifying and fixing issues sooner is being time and money savvy in the medium to long run. That is how developers started to look at the traditional product development life cycle, taking these statistics into consideration to try and create a more efficient lifecycle.
They started to push as much testing to the early phases of development as possible. This meant focusing the effort around unit testing and testing-as-we-code instead of delaying bug discovery until they were conducting end to end tests, system integration tests or even worse: bugs discovered by QA.
The whole approach echoes the famous motto “test early and test often”.
A whole new world!
We outlined the benefits of the shift left approach for cost control of software development. The improved cost management is a result of optimising how developers spend their time. Quickly identifying small flaws and fixing them early is more preferable than facing broken features later down the road. Beyond this, the shift left approach deserves some recognition when it comes to software engineers’ experience at work.
Spending more time fixing while you code is less mentally draining than the traditional 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. The loss of efficiency and motivation that the traditional approach meant for software engineers needed to change. Offering a better workflow and a smoother development experience can greatly increase developer happiness and can help to reduce turnover within teams.
This negative developer experience is just one of numerous indirect impacts that poor code quality and late-stage testing can have on a business. Ultimately, the shift left approach is a virtuous circle for IT teams.
The new shift left evolution
Shift left methodology has evolved over the years. Shift left advocates introduced a second key dimension to the approach: testing automation. One downside to the shift left approach was that it meant increasing the number of unit tests and tests that had to be created, increasing test repetition and tediousness. These shift left advocates see the shift left transition within a company or a development team as an opportunity to also try to automate as much of the testing process as possible in order to increase velocity even further and reduce the time developers spend testing.
One could argue that testing should be manual to be thorough, but the reality is that developers tend to skip testing altogether or lower their standards and attention if exposed to an overload of testing requirements. Experiencing the overload that shift left can represent when it comes to testing volumes encouraged the shift left supporters to promote the idea that shifting left is also an opportunity to introduce automated tests to a team’s processes. This can enable teams to execute tests repeatedly and at high frequency, ensuring no errors go under the radar. Constantly checking the system for early stage errors and fixing them immediately can improve the development lifecycle tenfold without overloading the software engineer.
Ok, enough teasing!
What do we believe is the best definition of shift left?
Shift left is an approach to software development which promotes more rigourous and more aggressive testing at the earliest stage possible in order to significantly reduce the amount of later stage tests and reduce the overall time spent fixing flaws.
Are you ready for shifting left? Ponicode is a shift left enabling tool which help declutter your testing pipeline and fix your legacy code with high velocity. You can try it for free today.
Interested in more code quality content? We discussed Code Quality during a special roundtable with CTO’s of the hottest french startups. We also investigated how DevSecOps is the new DevOps with code quality expert Paolo Zannier