Long term listeners will have heard me use the term "Shift Left" - but what does that mean? In this episode, I take a deeper dive into the "Shift Left" principal, why modern software development advocates it, and common places to find it happening.
Or listen at:
Published: Wed, 02 Feb 2022 17:17:11 GMT
Links
Transcript
Hello, and welcome back to the Better ROI from Software Development podcast.
In this episode, I wanted to talk about the term "Shift-Left".
Now it's probably a term you've heard me referred to in a number of episodes - but I thought I'd take the time just to explain a bit more what it actually means.
If we think of our traditional software developed process like a manufacturing line, work goes into a business analyst, then it goes into an architect, then it goes into the development team, then it goes into the testers, then it goes into the operations team.
It's easy to imagine that work travelling down a conveyor belt being operated on by each function.
If viewed from the side, the work travels down the conveyor belt from left to right. Shift-Left is the idea of bringing some of those later actions forward. If you viewed this from the side, these actions are happening earlier - thus, they have Shifted-Left.
There's very much a related principle in DevOps "If it hurts, do it more often".
Martin Fowler talks about this in an article, and I'll include a link in the show notes. In the article, he draws an exponential graph showing pain against time between actions. In short, the longer the time between those actions, the greater the pain will be. Thus, if it is hurting, do it more often. Think about if you haven't been to the gym in quite some time, it would be considerably more painful than if you've been going regularly.
Martin talks about three benefits of doing these things more often.
One, more often will likely mean smaller amounts of work - because conversely, we're avoiding batching, which often leads to too much work.
Two, improves feedback - we learn quicker.
Three, practise - we get better with practise. We make incremental improvements and find better ways of doing things. It becomes routine. And when it becomes routine, it's painless and easy.
As an industry, we find that Shifting-Left those things that hurt is generally a good idea. As an industry, we commonly Shift-Left activities like testing, deployment, product review and security testing.
If we take testing for example, Wikipedia talks about "Shift-Left testing" as:
"Shift-left testing is an approach to software testing and system testing in which testing is performed earlier in the lifecycle (i.e. moved left on the project timeline). It is the first half of the maxim "Test early and often."
We can do this in our teens by having testing be part of the development team's responsibility - rather than us, as we have done traditionally, handing it off to a separate team. We gain benefits from the development team understanding the work better because they need to test it and by greatly automating those tasks.
With deployment, we can deploy little and often using things like Continuous Integration, Deployment and Delivery that I talked about in episode 19-21. Again, we're moving the responsibility to the development team rather than where traditionally we would throw it over the wall to an operations team to do that deployment.
This gets us away from where traditionally a deployment may be a major event. It's quite common still for websites and systems to be down for hours, days, for weekends, because an update is being done.
And because it hurts so much for us to do that, we do the dysfunctional thing of batching lots of work to do at one time. We believe that because it's such a painful and traumatic event that what we should do is avoid doing it. Thus, what we do is we're backed up so much work, maybe 3, 6, 12 months worth of work, so we only have to do it the once.
Now, this doesn't help us. This hurts us.
Because it's such a major job, we're taking so much of a greater level of risk and holding so much investment back because we're batching it. We're changing so many things because we've batched it. We've got all that work that software developers have been working on, sitting, producing no benefit because we've batched it. And we're making it a major job.
And I also find this spirals because we start batching things - we find we want to release even less of them because of that risk. And as such, I've certainly seen organisations get to the point where they can't release because they have that much stuff batched - it's almost impossible to have any level of confidence that they have a system left once they've released it.
Whereas if we do it often, we greatly reduce the risk and we gain the benefits of that development investment quicker - a little and often, greatly reduces risk and allows us to see the benefit quicker.
If we talk about product reviews, it allows us just to get feedback in a timely manner. As I talked about in the last episode, the closer the customer is to the development team, the better, the quicker, the cheaper the outcomes.
For example, if you look at Scrum, they have a built in sprint review for regular reviews of the work the team are doing to garner that feedback.
There is also a growing number of technical products out there to help gain that feedback quickly. Even with mobile apps, which have traditionally been quite a difficult thing to get into our customers hands quickly, there are software packages out there and platforms to help us get that out to customers quickly to get the feedback that we need - get that feedback that we need now, not in 12 months time.
And security testing; now, this task has traditionally been left right until the end - waiting until the product is complete. And often it could have resulted in major issues being identified. At which point, right at the end of that product being developed, the business has a choice: it has a choice between accepting the risk of those security failings or a major delay while issues are resolved.
And I don't believe I'm overstating this by saying that some products have simply not been viable following a security review - because of the major issues identified. Effectively, it's a rewrite.
By having small, iterative releases, we can bring iterative security testing to play. Again, that feedback allows us to make course corrections when it's cheaper and less impactful. Tools and products out there to help us do this, but again, it becomes a responsibility of the team.
So whether it was testing, deployment, product reviews or security testing, we shift them left, we bring them earlier into the process, earlier into that production line. Most of the time by providing the responsibility through the development team.
So much of the Shifting-Left principle involves the development team taking up more responsibility - and I believe that is correct.
The less of a reliance that they have on other teams, the more effectively and efficiently they can work.
Now, this doesn't happen overnight. You can't expect a development team suddenly to be picking all these things up. The team needs the skills and the tools to help them achieve this. But by "Shifting-Left" and following the "if it hurts, do it more often" mantra, we make exceptional teams - teams that are closely aligned to our organisational outcomes, using quick, iterative development.
Thank you for taking the time to listen to this podcast. I look forward to speaking to you again next week.