4 ms·

For those not aware, Shift Left[1] is (at this point) an old term that was coined for a specific use case, but now refers to a general concept. The concept is t

For those not aware, Shift Left[1] is (at this point) an old term that was coined for a specific use case, but now refers to a general concept. The concept is that, if you do needed things earlier in a product cycle, it will end up reducing your expense and time in the long run, even if it seems like it's taking longer for you to "get somewhere" earlier on. I think this[2] article is a good no-nonsense explainer for "Why Shift Left?". [1] https://en.wikipedia.org/wiki/Shift-left_testing https://en.wikipedia.org/wiki/Shift-left_testing [2] https://www.dynatrace.com/news/blog/what-is-shift-left-and-what-is-shift-right/ https://www.dynatrace.com/news/blog/what-is-shift-left-and-w...

leoc 2y ago
So “shift left” is roughly equivalent to “tests first” or “TDD”?
- marcellus23 2y ago
  I would say tests first/TDD is a form of shifting left, but it can encompass more than that.
- 01HNNWZ0MV43FF 2y ago
  It can also mean manual testing earlier. Valve credits playtesting early and playtesting often for their success with Half-Life, Half-Life 2, and other games.
  - Fuzzwah 2y ago
    Not just when they play tested but how. Silently watching someone play, only taking notes. No debrief. Source: the week I spent in the Valve offices in 2005, having Valve staff playing our in development HL2 mod.
    - CodeAndCuffs 2y ago
      Was it Dystopia, by chance?
- mehagar 2y ago
  More broadly it includes moving activities that are normally performed at a later stage so that they are earlier in the process. The idea is that defects found later in the process are more costly.
- hitchstory 2y ago
  That's just one example of it. Other examples: * Replacing automated tests with (quicker) type checking and running it on a git commit hook instead of CI. * Replacing slower tests with faster tests. * Running tests before merging a PR instead of after. * Replacing a suite of manual tests with automation tests. etc.
  - 0xbadcafebee 2y ago
    Or, again more generally: - implementing security features earlier (DevSecOps) - implement tracing and metrics/analysis tools earlier, use them to test and debug apps earlier (as opposed to laptop-based solutions) - building the reliable production model earlier (don't start with a toy model on your laptop if you're gonna end up with an RDS instance in AWS; build the big production thing first, and use it early on) - add synthetic end-to-end tests early on The linked article is talking about Shift Left in the context of developing semiconductors, so you can see how it can be applied to anything. Just do the needed thing earlier, in order to iterate faster, improve quality, reduce cost, ship faster.
    - skybrian 2y ago
      Yes, it can be applied to anything, but might not pay off with software like it does with semiconductors? Better tests and more static analysis are useful, but teams will often work on making their releases faster and easier, iterating more frequently, and then testing some things in production. We don’t want our software to be too brittle, so it should tolerate more variation in performance. But with chip design, they can’t iterate that fast and performance is more important, so they are doing more design and testing before the expensive part, using increasingly elaborate simulations.
  - js8 2y ago
    So aside from automation (which also has tradeoffs), when you shift left, what gets shifted right?
    - saynay 2y ago
      The knowledge needed to do the 'shift-left' tasks. The downside of making your developers take on more tasks that used to be handled by someone further down the chain is they need to know how to do those tasks.
- crabbone 2y ago
  No, not really. It's a concept from the bygone era, before X-as-a-service took over a lot of software categories. It was intended to minimize friction between the QA and the development teams at the time the product was handed to QA. If the product had multiple defects, incrementally discovered, it would have to travel back and forth between the QA and the developers, stalling the development of the next version and generally creating a lot of noise and inconvenience due to the surrounding bureaucracy. There's no need to write tests upfront for you to shift left. All shift left means is that testing happens during development. Whether you start by writing tests and then write the actual program or the other way around -- doesn't matter.
coryrc 2y ago
No evidence most of the activities actually save money with modern ways of delivering software (or even ancient ways of delivering software; I looked back and the IBM study showing increasing costs for finding bugs later in the pipeline was actually made up data!)
- coryrc 2y ago
  To be more specific, let's say I can write an e2e test on an actual pre-prod environment, or I can invest much development and ongoing maintenance to develop stub responses so that the test can run before submit in a partial system. How much is "shifting left" worth versus investing in speeding up the deployment pipeline and fast flag rollout and monitoring? Nobody I've worked with can ever quantify the ROI for elaborate take test environments, but somebody made an okr so there you go. Far be it we follow actual research done on modern software... http://dora.dev http://dora.dev
  - cogman10 2y ago
    In fact, in my experience, these elaborate test environments and procedures cripple products. I'm firmly of the opinion that if a test can't be run completely locally then it shouldn't be run. These test environments can be super fragile. They often rely on a symphony of teams ensuring everything is in a good state all the time. But, what happens more often than not, is one team somewhere deploys a broken version of their software to the test environment (because, of course they do) in order to run their fleet of e2e tests. That invariably ends up blowing up the rest of the org depending on that broken software and heaven help you if the person that deployed did it at 5pm and is gone on vacation. This rippling failure mode happens because it's easier to write e2e tests which depend on a functional environment than it is to write and maintain mock services and mock data. Yet the mock services and data are precisely what you need to ensure someone doesn't screw up the test environment in the first place.
    - coryrc 2y ago
      There are many reasons you want to be able to turn up your whole stack quickly; disaster recovery is just one of them. And if you can turn up your environment quickly then why not have multiple staging environments? You start with the most recent of yours and everyone else's prod version, then carrots combinations from there Obviously this is for large-scale systems and not small teams.
deleted 2y ago
[deleted]
98codes 2y ago
What helped me finally remember "left of what, exactly" is to imagine a timeline, left to right. Shifting left is moving things earlier in that timeline.
DeathArrow 2y ago
Do the hard things first?
- Buttons840 2y ago
  Do the things that are hard and important first.
hammock 2y ago
Sounds like the bottleneck concept from Goldratt’s The Goal
- infogulch 2y ago
  I'm familiar with both concepts and they don't seem related imo. Maybe if you applied bottleneck theory to process design in the abstract? Sorry I can't evaluate this comparison further, I must have run out of my quota for Abstract Reasoning Tokens today.
  - hammock 2y ago
    "Shifting left" is like moving the fat kid on the hike to the front of the line
bigs 2y ago
Sounds like a similar/parallel thought to the project management waterfall paradigm whereby the earlier you get things correct (left) the less costly it is in the long run or conversely if you have to go and re-do things later on (right) you’re in for a shock (either cost, time or quality).
- tromp 2y ago
  Funny how correct is not associated with right. The normal association is reflected in he Haskell Either datatype for describing computations that either run into some error (Left error) or run successfully producing a value (Right value).
  - lolinder 2y ago
    That's because the association isn't right or wrong, it's progressing or not progressing, deriving from reading order. A Left value typically halts computation there and returns something to the user, whereas a Right value allows you to move on. One nice side effect of tying the mnemonic to reading direction rather than homonyms is that it carries over across languages better (though still imperfectly).
  - Centigonal 2y ago
    a sinister observation, dexterously phrased.
- brightball 2y ago
  I’ve come to the conclusion that Kent Beck got just about everything right with Extreme Programming. There’s just not a formal training industry out there pushing it so many more people are selling and invested in other approaches with a lot of warts.
  - devjab 2y ago
    XP is almost the opposite or shift right, similar to how every other “agile” development form pushes the necessary work forward. I think it’s telling that none of the modern software design systems seem to have given us a world where our industry is capable of delivering software on time and within budget. They’ve been around for 20 years, places follow them religiously and still fail. Maybe everything about those concepts are just wrong? I mean, you can have people like Uncle Bob who’ll tell you that “you just got it wrong”. He’s also always correct in this, but if so many teams “get it wrong” then maybe things like clean, xp and so on simply suck?
rusk 2y ago
”a stitch in time saves nine” ”prevention is better than cure” [ante-] ”closing the stable door after the horse has bolted”
polishdude20 2y ago
Sounds like the exact thing we never did at my previous employer. Just do the bare minimum to get it out the door and then fix it later.
- infotecht 2y ago
  Shift Left is about doing more work earlier in a process for efficiency -- it sounds like you at your previous employer were shifting right instead?
- ajross 2y ago
  That's an orthogonal concept. The idea of "shift left" is that you have work that needs to be done regardless (it's not an analysis of "bare minimum"), but tends strongly to be serialized for organizational reasons. And you find ways to parallelize the tasks. The classic example is driver development. No one, even today, sits down and writes e.g. a Linux driver until after first silicon has reached the software developers. Early software is all test stuff, and tends to be written to hardware specs and doesn't understand the way it'll be integrated. So inevitably your driver team can't deliver on time because they need to work around nonsense. And it feeds back. The nonsense currently being discovered by the driver folks doesn't get back to the hardware team in time to fix it, because they're already taping out the next version. So nonsense persists in version after version. Shift left is about trying to fix that by bringing the later stages of development on board earlier.
  - cellular 2y ago
    Everywhere i worked we had drivers running well before silicon came back. We used simulators for hardware. Using parts of existing hardware when possible and hacked Microsoft sw emulation to behave as our hardware would. When the hardware came back, it was less than a day to get the driver running.
- SexyKitty17 2y ago
  [flagged]
- createaccount99 2y ago
bloodyplonker22 2y ago
I had management who were so enthused about "shift left" that we shifted far left and broke the shifter, or perhaps, mis-shifted. Now we spend too much time developing test plan and testing and arguing about PRD that we actually deliver more slowly than competitor by a lot.
- hinkley 2y ago
  Another flavor of this I've encountered is people in the management chain who can only think about faults per time interval and not about faults per interaction. So you make a tool that prevents errors and speeds up a process, now people use it four times as much, and now they wonder why they're only seeing half as many faults instead of an order of magnitude less. We are humans. We cannot eliminate errors, we can only replace them with a smaller number of different errors. Or as in your case, a larger number of them.
theGnuMe 2y ago
Except it doesn’t work. What does work is domain experience. You get this by iterating quickly.
MintChipMonk 2y ago
> The concept is that, if you do needed things earlier in a product cycle, it will end up reducing your expense and time in the long run, even if it seems like it's taking longer for you to "get somewhere" earlier on. Isn't ignoring the early steps that could save time later also known as false economy? https://en.wikipedia.org/wiki/False_economy https://en.wikipedia.org/wiki/False_economy
- marcosdumay 2y ago
  Ignoring earlier steps is the basis of Agile. It's only a false economy if they are the correct steps. If it turns out that they are wrong, it's a very real one.
JohnFen 2y ago
Thanks for the explanation. I have always called this "front loading" and it's a concept that's been around for decades. Front loading almost always reduces development time and increases quality, but to many devs, it feels like time-wasting.

leoc 2y ago

So “shift left” is roughly equivalent to “tests first” or “TDD”?

marcellus23 2y ago
I would say tests first/TDD is a form of shifting left, but it can encompass more than that.
01HNNWZ0MV43FF 2y ago
It can also mean manual testing earlier. Valve credits playtesting early and playtesting often for their success with Half-Life, Half-Life 2, and other games.
- Fuzzwah 2y ago
  Not just when they play tested but how. Silently watching someone play, only taking notes. No debrief. Source: the week I spent in the Valve offices in 2005, having Valve staff playing our in development HL2 mod.
  - CodeAndCuffs 2y ago
    Was it Dystopia, by chance?
mehagar 2y ago
More broadly it includes moving activities that are normally performed at a later stage so that they are earlier in the process. The idea is that defects found later in the process are more costly.
hitchstory 2y ago
That's just one example of it. Other examples: * Replacing automated tests with (quicker) type checking and running it on a git commit hook instead of CI. * Replacing slower tests with faster tests. * Running tests before merging a PR instead of after. * Replacing a suite of manual tests with automation tests. etc.
- 0xbadcafebee 2y ago
  Or, again more generally: - implementing security features earlier (DevSecOps) - implement tracing and metrics/analysis tools earlier, use them to test and debug apps earlier (as opposed to laptop-based solutions) - building the reliable production model earlier (don't start with a toy model on your laptop if you're gonna end up with an RDS instance in AWS; build the big production thing first, and use it early on) - add synthetic end-to-end tests early on The linked article is talking about Shift Left in the context of developing semiconductors, so you can see how it can be applied to anything. Just do the needed thing earlier, in order to iterate faster, improve quality, reduce cost, ship faster.
  - skybrian 2y ago
    Yes, it can be applied to anything, but might not pay off with software like it does with semiconductors? Better tests and more static analysis are useful, but teams will often work on making their releases faster and easier, iterating more frequently, and then testing some things in production. We don’t want our software to be too brittle, so it should tolerate more variation in performance. But with chip design, they can’t iterate that fast and performance is more important, so they are doing more design and testing before the expensive part, using increasingly elaborate simulations.
- js8 2y ago
  So aside from automation (which also has tradeoffs), when you shift left, what gets shifted right?
  - saynay 2y ago
    The knowledge needed to do the 'shift-left' tasks. The downside of making your developers take on more tasks that used to be handled by someone further down the chain is they need to know how to do those tasks.
crabbone 2y ago
No, not really. It's a concept from the bygone era, before X-as-a-service took over a lot of software categories. It was intended to minimize friction between the QA and the development teams at the time the product was handed to QA. If the product had multiple defects, incrementally discovered, it would have to travel back and forth between the QA and the developers, stalling the development of the next version and generally creating a lot of noise and inconvenience due to the surrounding bureaucracy. There's no need to write tests upfront for you to shift left. All shift left means is that testing happens during development. Whether you start by writing tests and then write the actual program or the other way around -- doesn't matter.

coryrc 2y ago

No evidence most of the activities actually save money with modern ways of delivering software (or even ancient ways of delivering software; I looked back and the IBM study showing increasing costs for finding bugs later in the pipeline was actually made up data!)

coryrc 2y ago
To be more specific, let's say I can write an e2e test on an actual pre-prod environment, or I can invest much development and ongoing maintenance to develop stub responses so that the test can run before submit in a partial system. How much is "shifting left" worth versus investing in speeding up the deployment pipeline and fast flag rollout and monitoring? Nobody I've worked with can ever quantify the ROI for elaborate take test environments, but somebody made an okr so there you go. Far be it we follow actual research done on modern software... http://dora.dev http://dora.dev
- cogman10 2y ago
  In fact, in my experience, these elaborate test environments and procedures cripple products. I'm firmly of the opinion that if a test can't be run completely locally then it shouldn't be run. These test environments can be super fragile. They often rely on a symphony of teams ensuring everything is in a good state all the time. But, what happens more often than not, is one team somewhere deploys a broken version of their software to the test environment (because, of course they do) in order to run their fleet of e2e tests. That invariably ends up blowing up the rest of the org depending on that broken software and heaven help you if the person that deployed did it at 5pm and is gone on vacation. This rippling failure mode happens because it's easier to write e2e tests which depend on a functional environment than it is to write and maintain mock services and mock data. Yet the mock services and data are precisely what you need to ensure someone doesn't screw up the test environment in the first place.
  - coryrc 2y ago
    There are many reasons you want to be able to turn up your whole stack quickly; disaster recovery is just one of them. And if you can turn up your environment quickly then why not have multiple staging environments? You start with the most recent of yours and everyone else's prod version, then carrots combinations from there Obviously this is for large-scale systems and not small teams.

deleted 2y ago

[deleted]

98codes 2y ago

What helped me finally remember "left of what, exactly" is to imagine a timeline, left to right. Shifting left is moving things earlier in that timeline.

DeathArrow 2y ago

Do the hard things first?

Buttons840 2y ago
Do the things that are hard and important first.

hammock 2y ago

Sounds like the bottleneck concept from Goldratt’s The Goal

infogulch 2y ago
I'm familiar with both concepts and they don't seem related imo. Maybe if you applied bottleneck theory to process design in the abstract? Sorry I can't evaluate this comparison further, I must have run out of my quota for Abstract Reasoning Tokens today.
- hammock 2y ago
  "Shifting left" is like moving the fat kid on the hike to the front of the line

bigs 2y ago

Sounds like a similar/parallel thought to the project management waterfall paradigm whereby the earlier you get things correct (left) the less costly it is in the long run or conversely if you have to go and re-do things later on (right) you’re in for a shock (either cost, time or quality).

tromp 2y ago
Funny how correct is not associated with right. The normal association is reflected in he Haskell Either datatype for describing computations that either run into some error (Left error) or run successfully producing a value (Right value).
- lolinder 2y ago
  That's because the association isn't right or wrong, it's progressing or not progressing, deriving from reading order. A Left value typically halts computation there and returns something to the user, whereas a Right value allows you to move on. One nice side effect of tying the mnemonic to reading direction rather than homonyms is that it carries over across languages better (though still imperfectly).
- Centigonal 2y ago
  a sinister observation, dexterously phrased.
brightball 2y ago
I’ve come to the conclusion that Kent Beck got just about everything right with Extreme Programming. There’s just not a formal training industry out there pushing it so many more people are selling and invested in other approaches with a lot of warts.
- devjab 2y ago
  XP is almost the opposite or shift right, similar to how every other “agile” development form pushes the necessary work forward. I think it’s telling that none of the modern software design systems seem to have given us a world where our industry is capable of delivering software on time and within budget. They’ve been around for 20 years, places follow them religiously and still fail. Maybe everything about those concepts are just wrong? I mean, you can have people like Uncle Bob who’ll tell you that “you just got it wrong”. He’s also always correct in this, but if so many teams “get it wrong” then maybe things like clean, xp and so on simply suck?

rusk 2y ago

”a stitch in time saves nine” ”prevention is better than cure” [ante-] ”closing the stable door after the horse has bolted”

polishdude20 2y ago

Sounds like the exact thing we never did at my previous employer. Just do the bare minimum to get it out the door and then fix it later.

infotecht 2y ago
Shift Left is about doing more work earlier in a process for efficiency -- it sounds like you at your previous employer were shifting right instead?
ajross 2y ago
That's an orthogonal concept. The idea of "shift left" is that you have work that needs to be done regardless (it's not an analysis of "bare minimum"), but tends strongly to be serialized for organizational reasons. And you find ways to parallelize the tasks. The classic example is driver development. No one, even today, sits down and writes e.g. a Linux driver until after first silicon has reached the software developers. Early software is all test stuff, and tends to be written to hardware specs and doesn't understand the way it'll be integrated. So inevitably your driver team can't deliver on time because they need to work around nonsense. And it feeds back. The nonsense currently being discovered by the driver folks doesn't get back to the hardware team in time to fix it, because they're already taping out the next version. So nonsense persists in version after version. Shift left is about trying to fix that by bringing the later stages of development on board earlier.
- cellular 2y ago
  Everywhere i worked we had drivers running well before silicon came back. We used simulators for hardware. Using parts of existing hardware when possible and hacked Microsoft sw emulation to behave as our hardware would. When the hardware came back, it was less than a day to get the driver running.
SexyKitty17 2y ago
[flagged]
createaccount99 2y ago

bloodyplonker22 2y ago

I had management who were so enthused about "shift left" that we shifted far left and broke the shifter, or perhaps, mis-shifted. Now we spend too much time developing test plan and testing and arguing about PRD that we actually deliver more slowly than competitor by a lot.

hinkley 2y ago
Another flavor of this I've encountered is people in the management chain who can only think about faults per time interval and not about faults per interaction. So you make a tool that prevents errors and speeds up a process, now people use it four times as much, and now they wonder why they're only seeing half as many faults instead of an order of magnitude less. We are humans. We cannot eliminate errors, we can only replace them with a smaller number of different errors. Or as in your case, a larger number of them.

theGnuMe 2y ago

Except it doesn’t work. What does work is domain experience. You get this by iterating quickly.

MintChipMonk 2y ago

> The concept is that, if you do needed things earlier in a product cycle, it will end up reducing your expense and time in the long run, even if it seems like it's taking longer for you to "get somewhere" earlier on. Isn't ignoring the early steps that could save time later also known as false economy? https://en.wikipedia.org/wiki/False_economy https://en.wikipedia.org/wiki/False_economy

marcosdumay 2y ago
Ignoring earlier steps is the basis of Agile. It's only a false economy if they are the correct steps. If it turns out that they are wrong, it's a very real one.

JohnFen 2y ago

Thanks for the explanation. I have always called this "front loading" and it's a concept that's been around for decades. Front loading almost always reduces development time and increases quality, but to many devs, it feels like time-wasting.