Everywhere i worked we had drivers running well before silicon came back.

We used simulators for hardware. Using parts of existing hardware when possible and hacked Microsoft sw emulation to behave as our hardware would.

When the hardware came back, it was less than a day to get the driver running.

In fact, in my experience, these elaborate test environments and procedures cripple products.

I'm firmly of the opinion that if a test can't be run completely locally then it shouldn't be run. These test environments can be super fragile. They often rely on a symphony of teams ensuring everything is in a good state all the time. But, what happens more often than not, is one team somewhere deploys a broken version of their software to the test environment (because, of course they do) in order to run their fleet of e2e tests. That invariably ends up blowing up the rest of the org depending on that broken software and heaven help you if the person that deployed did it at 5pm and is gone on vacation.

This rippling failure mode happens because it's easier to write e2e tests which depend on a functional environment than it is to write and maintain mock services and mock data. Yet the mock services and data are precisely what you need to ensure someone doesn't screw up the test environment in the first place.

Shift-left comes from the world before everyone was selling services. In that world shipping service packs was the way to fix problems discovered after a release, and releases were years apart.

From a QA perspective, I greatly regret that the world of infrequent releases is mostly gone. There are few kinds of products that still hold onto the old strategy, but this is a dying art.

I see the world of services with DevOps, push on green etc. strategies as a kind of fast-food of software development. A kind of way of doing things that allows one to borrow from the future self by promising to improve the quality eventually, but charging for that future improved quality today.

There are products where speeding the rollout is a bad idea. Anything that requires high reliability is in that category. And the reason is that highly reliable systems need to collect mileage before being released. For example, in storage products, it's typical to have systems run for few months before they are "cleared for release". Of course, it's possible to continue development during this time, but it's a dangerous time for development because at any moment the system can be sent back to developers, and they would have to incorporate their more recent changes into the patched system when they restart the development process. I.e. a lot of development effort can be potentially wasted before the system is sent out to QA and the actual release. And, to amortize this waste, it's better to release less frequently. It's also better to approach the time when the system is handed to QA with a system already well-tested, as this will minimize the back-and-forth between the QA and the development -- and that's the problem shift-left was intended to solve.

NB. Here's another, perhaps novel thought for the "push on green" people. Once it was considered a bad idea for the QA to be aware of implementation details. Testing was seen as an experiment, where the QA were the test subjects. This also meant that exposing the QA to the internal details of the systems or the rationale that went into building it would "spoil" the results. In such a world, allowing the QA to see a half-baked system would be equivalent to exposing them to the details of the system's implementation, thus undermining their testing effort. The QA were supposed to receive the technical documentation for the system and work from it, trying to use the system as documented.

No argument, but there can be limitations on how much you can speed up the deployment pipeline. In particular, the article is about integrated circuit development (actually about systems made of many ICs), where a “production deployment” takes months and many, many millions of dollars, and there’s not much you can do about it.

I heard a story decades ago about a software team that got a new member transferred in from the IC design department. The new engineer checked in essentially zero bugs. The manager asked what the secret was, and the new engineer said “wait, we’re allowed to have bugs?”

Pressman i.e. https://www.theregister.com/2021/07/22/bugs_expense_bs/

In a waterfall, single-deliverable model it wouldn't surprise me there is some increase in costs the later a bug is discovered, but if you're in that world you have more obvious problems to tackle.

People still use the Pressman numbers. So much for "data-driven decision making"...

That's because the association isn't right or wrong, it's progressing or not progressing, deriving from reading order. A Left value typically halts computation there and returns something to the user, whereas a Right value allows you to move on.

One nice side effect of tying the mnemonic to reading direction rather than homonyms is that it carries over across languages better (though still imperfectly).

a sinister observation, dexterously phrased.

XP is almost the opposite or shift right, similar to how every other “agile” development form pushes the necessary work forward. I think it’s telling that none of the modern software design systems seem to have given us a world where our industry is capable of delivering software on time and within budget. They’ve been around for 20 years, places follow them religiously and still fail.

Maybe everything about those concepts are just wrong? I mean, you can have people like Uncle Bob who’ll tell you that “you just got it wrong”. He’s also always correct in this, but if so many teams “get it wrong” then maybe things like clean, xp and so on simply suck?

Or, again more generally:

- implementing security features earlier (DevSecOps)

- implement tracing and metrics/analysis tools earlier, use them to test and debug apps earlier (as opposed to laptop-based solutions)

- building the reliable production model earlier (don't start with a toy model on your laptop if you're gonna end up with an RDS instance in AWS; build the big production thing first, and use it early on)

- add synthetic end-to-end tests early on

The linked article is talking about Shift Left in the context of developing semiconductors, so you can see how it can be applied to anything. Just do the needed thing earlier, in order to iterate faster, improve quality, reduce cost, ship faster.

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

Not just when they play tested but how. Silently watching someone play, only taking notes. No debrief.

Source: the week I spent in the Valve offices in 2005, having Valve staff playing our in development HL2 mod.

"Shifting left" is like moving the fat kid on the hike to the front of the line