Applications, particularly those for mobile devices, are becoming increasingly important in today's competitive business environment.
Statista predicted the so-called app economy will experience a compound annual growth rate of 37% between 2016 and 2021, which would put it at $6.3 trillion by now.
Although there are no published numbers of the actual size of the market today, one can safely say it is large.
A factor that Statista's predictions did not foresee is the impact of COVID-19 on business. It's safe to say the pandemic will continue to drive even greater emphasis on apps as work styles become more hybrid, and customers demand more streamlined, often contactless, shopping experiences.
One thing is for sure: a business's success is inextricably tied, not only to its ability to develop apps quickly, but also to increase functionality, to take advantage of a rapidly-shifting marketplace in which the bar is constantly being raised.
In response to the increased importance of applications, DevOps evolved to create an integrated, more effective approach to software development. Traditional software development typically consists of three discrete parts: the software development itself, quality assurance (QA) or testing, and operations (the supporting IT infrastructure).
This somewhat disjointed process has several disadvantages, not least of which is that the testing / QA portion typically took place towards the end of the process. This meant any bugs or other imperfections were picked up very late in the process, making them much harder − and radically more expensive − to correct.
Obviously, just from a cost point of view, moving the test / QA phase to earlier in the process has the potential to save enormous amounts of money, and time, because a defect that is detected early is quicker to fix because it has fewer interdependencies.
In fact, DevOps, complementary to Agile software development, with its focus on rapid, iterative delivery of bite-sized pieces of software, has become known for continuous testing.
Just imagine if shift left had been employed in the design and build of Medupi and Kusile power stations.
But what's all this about shift left, you may be asking? Well, if you conceptualise the software development process as a linear progression with testing towards the extreme right of the diagram, shifting the test phase to the left would indicate it takes place earlier in the process.
I should reiterate, though, the idea is not simply to shift the testing phase from one point to another, but rather to make it an integral part of the whole process, which entails involving software developers.
But wait, there's more
- Massive potential costs are just one of the benefits to be gained from adopting a shift left approach to testing. Some of the other benefits include:
- Greater potential use of automation across a unified testing environment. This means that already identified problems will not be allowed to crop up again, and the human factor in testing is eliminated. At the same time, human testers are freed up to do more interesting tasks.
- Multiple tests can be conducted at once, making the whole testing process more stringent.
- Early testing will also identify problem areas that should be tracked throughout the whole process.
- Significant time saving. As noted above, the earlier defects are detected, the easier and quicker they are to fix. This in turn means the interval between releases can be reduced.
- Enhanced quality. Integrating testing into the development process from the get-go means the quality of the end product is improved, leading to greater customer satisfaction. Applications that are delivered more quickly and at better quality − what's not to like?
- Performance. If performance is considered early in the process, there are significant cost savings from an infrastructure perspective, as well as application delivery timelines.
The bigger picture
Shift left thinking began in the testing world, but it should be apparent that it's intrinsic to the Agile methodologies associated with DevOps as a whole. At a generic level, shift left is all about identifying potential bottlenecks and challenges early on, when it's still possible to tweak the design.
Just imagine if shift left had been employed in the design and build of Medupi and Kusile power stations. The huge budget and time overruns can be at least partially traced to the fact that serious design flaws only came to light at the last minute − and fixing them at this late stage consumes large amounts of money and time.
Of course, the feeding frenzy at the money trough didn't help either.
Shift left thinking can also be beneficial in the security environment. Nobody needs reminding of the scale and sophistication of today's threat landscape and, clearly, the traditional route of bolting on security solutions is not sustainable. Integrating security into the fundamental design of the software is much more effective.
The same approach could also be applied to the design of the software.
Shift left is not the panacea for all ills, but it's a way of thinking that, in software development at least, has the potential to deliver a set of real benefits, not the least of which is more satisfied business partners.
It's really an idea whose time has come.
In my next article, I will explain where in specific situations there are benefits to shifting right and how to implement shift left.
Share