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.

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?

To me that makes sense, you'd want stuff out the door asap and see if it can work at all, not waste time on unproven ideas.

[flagged]