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

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.

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.