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

In my org [1], "shift left" means developers do more work sooner.

So before we clearly clarify product requirements, we start the build early with assumptions that can change. Sometimes it works, sometimes it does not, which just means we end up net neutral.

But an executive somewhere up the management chain can claim more productivity. Lame.

[1] I work at a bank.

Aka A stitch in time saves nine.

We seem to be hell bent on ignoring age old common sense repeatedly in our work while simultaneously inventing new names for them. Wonder why? Money? Survival? Personal ambition?

These concepts are not worth the paper you wipe your backside with unless you have a manager and a team that cares.

I'm in chip design and our VP's and C level execs have been saying "shift left" for the last year. Every time someone in the Q&A asks "What does shift left mean?" No one talks this way except for executives. We just joke "The left shift key isn't working on my keyboard" or some other nonsense.

In software shifting left often also means putting more tasks into the hands of the person with the most context, aka, moving deployment from ops to developers.

The main benefits you get from this is reduced context switching, increased information retention, increased ownership.

But it has to go with tooling, and process that enables that. If you have a really long deployment process where devs can get distracted then they will lose context switching between tasks. If you make every Dev a one man army that has to do everything on their own you won't be able to ship anything and your infra will be a disjointed mess.

They key thing is reducing toil, and increasing decision making power within a single team/person.

From the sound of the article they might be just squishing two teams together? What's the advancement that made the two steps be able to happen at the same time?

As soon as I saw “shift left” I knew I wanted to double down.

> Optimization strategies have shifted from simple power, performance, and area (PPA) metrics to system-level metrics, such as performance per watt. “If you go back into the 1990s, 2000s, the road map was very clear,”

Tell me you work for Intel without telling me you work for Intel.

> says Chris Auth, director of advanced technology programs at Intel Foundry.

Yeah that’s what I thought. The breathlessness of Intel figuring out things that everyone else figured out twenty years ago doesn’t bode well for their future recovery. They will continue to be the laughing stock of the industry if they can’t find more self reflection than this.

Whether this is their public facing or internal philosophy hardly matters. Over this sort of time frame most companies come to believe their own PR.

Imagine the world of software if your editor, compiler, virtual machine, etc. each cost a million dollars a year per programmer.

This is reality in VLSI CAD.

Now you understand why everything in hardware engineering is stupidly dysfunctional.

We don't need "shift left". We need tools that don't cost a megabuck.

The shift right parts of the article are more interesting...

Can we please stop naming things after directions? I don't want to shift left/right/up/down and my data center has no north/south/east/west. Just say what you actually want to say without obfuscating.