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.

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).

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!)

> 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

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

Sounds like the bottleneck concept from Goldratt’s The Goal

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

Do the hard things first?

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.

”a stitch in time saves nine”

”prevention is better than cure”

[ante-] ”closing the stable door after the horse has bolted”

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.