Shift Left Is the Tip of the Iceberg

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 [2] https://www.dynatrace.com/news/blog/what-is-shift-left-and-w...

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

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.

So aside from automation (which also has tradeoffs), when you shift left, what gets shifted right?

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.