When you do root-cause analysis, you always discover functionalities missed in testing or defects that were put into production that could have been identified earlier in the process.
Hi, I’m Peter Nichol, Data Science CIO.
What does shift left mean?
Today, we’re going to talk about the concept of “shifting left and shifting right.” Then we’ll cover the “shifting in reverse” theory. All right, I made up the “shifting in reverse” theory. Shifting left and shifting right are what we’ll explore today.
Shifting left is a concept that was introduced within the last 10 years or so, but it originated in the 1950s when IBM introduced the Harvard Mark I supercomputer, also known as the IBM Automatic Sequence Controlled Calculator (ASCC). The level of technological advancement at the time was a huge deal. This computer cost about $5.7 million in today’s dollars, and it weighed 9,445 pounds or 4.7 tons. It also came with over 500 miles of wires, three million connectors, and over 35,000 contacts. This was an extremely complicated computer that took years to design, assemble, and build fully. Nevertheless, the computer was a success, and it was pretty powerful for its time.
How shift left originated
While the computer was powerful, developers didn’t have an easy time working with this massive machine. If developers had a code mistake, they had to rerun their code (cards), and rerunning code was expensive because the cost of computing was expensive. A concept was developed to move testing to earlier in the process to decrease risk and lower costs. Hence, the idea of shift left was coined and began to take hold.
What are the advantages of shift left?
There are three significant benefits in adopting a shift-left technology culture.
The first is early detection of failure points. By testing earlier in the lifecycle, developers can identify defects, code breaks, and problems with logic earlier in the lifecycle. This leads us right into our second benefit, which is cost avoidance. When we test earlier in the process, we reduce the cost of fixing defects and decrease the likelihood of extensive remediation efforts. The third benefit is that we can get functionality into production much more effectively and sooner because we can reduce the lifecycle. Shift-left delivery models also offer benefits such as:
- Developers test their code
- Modularized functions
- Co-location of developers and testers
How does shift right fit into the mix?
This leads us to the concept of shifting right. Shifting left—testing earlier in the process—seems like common sense. It just sounds reasonable.
When we look at shifting right, the logic seems less clear. Why would we shift right when we just put all this time and effort into shifting left? Also, why shift right at all?
The concept of shifting right isn’t mutually exclusive from the idea of shifting left. Surprisingly, the concepts are complementary.
What are some excellent examples of shifting right?
The idea behind shifting right is that once functionality goes into production, no additional testing is performed. That functionality is, in essence, forgotten. From there on, we assume the functionality is working as expected. Then, of course, new functionality is tested immediately post-deployment. However, here we’re talking about a week or two later. Does your IT team continue to test after that two-week window? Doubtful. We assume that there won’t be defects after that point and, if there are, the business users will discover and report them.
Do we want our business partners and customers to find defects and problems with production? Hell, no. We want to fix them proactively before our business partners identify those problems. This is precisely where the shift right mindset adds value. I’ll explain the three main concepts behind shift right briefly, including A/B testing, dark launching, and chaos testing.
- A/B testing: This concept looks at the initial design requirements and ensures that they work in production.
- Dark launching: This is the process of unofficially slowly releasing functionality to production. The key here is that the functionality being released isn’t officially announced to users. LinkedIn is well known for leveraging this approach as they release functionality to select groups of influencers. Functionality appears on a page and is immediately available. Members can either leverage the new features or not. However, rarely are they released to all members.
- Chaos testing: This is the idea of making sure we have unplanned test scenarios as part of our test plan. Chaos testing can involve simulated stress testing or injecting other types of errors or defects into the mix. For example, we might deliberately get the system to throw errors, inject rare scenarios, or run some edge-case scenarios when trying to break a piece of functionality that didn’t handle the exception effectively.
Here are some additional examples of shift-right concepts:
- Canary testing
- Continuous quality monitoring (CQM)
- Code instrumentation
- Production user monitoring
- Production testing
As you race into your workweek, ask yourself, “Am I leveraging the shift-left methodology? Am I testing as early in that lifecycle as possible?” Once you have those answers, you secondarily ask, “Am I shifting right? Do I have controls in place to test and retest functionality after it’s in production?”
Save your users the stress of stumbling into production defects. Instead, start finding defects before your business partners do.
If you found this article helpful, that’s great! Also, check out my books, Think Lead Disrupt and Leading with Value. They were published in early 2021 and are available on Amazon and at http://www.datsciencecio.com/shop for author-signed copies!
Hi, I’m Peter Nichol, Data Science CIO. Have a great day!