Shift Left Is the Tip of the Iceberg

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

I would say tests first/TDD is a form of shifting left, but it can encompass more than that.

It can also mean manual testing earlier. Valve credits playtesting early and playtesting often for their success with Half-Life, Half-Life 2, and other games.

More broadly it includes moving activities that are normally performed at a later stage so that they are earlier in the process. The idea is that defects found later in the process are more costly.

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.

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.

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?

Was it Dystopia, by chance?

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.

Why can’t you shift the “someone further down the line” left along with the task?

No, not really. It's a concept from the bygone era, before X-as-a-service took over a lot of software categories. It was intended to minimize friction between the QA and the development teams at the time the product was handed to QA. If the product had multiple defects, incrementally discovered, it would have to travel back and forth between the QA and the developers, stalling the development of the next version and generally creating a lot of noise and inconvenience due to the surrounding bureaucracy.

There's no need to write tests upfront for you to shift left. All shift left means is that testing happens during development. Whether you start by writing tests and then write the actual program or the other way around -- doesn't matter.

This is interesting. Seems like it would mean something like having QA or infosec pair program with app devs. I'm sure somebody does this and am curious how it works out in practice.

Yes, it can be applied to anything, but might not pay off with software like it does with semiconductors? Better tests and more static analysis are useful, but teams will often work on making their releases faster and easier, iterating more frequently, and then testing some things in production. We don’t want our software to be too brittle, so it should tolerate more variation in performance.

But with chip design, they can’t iterate that fast and performance is more important, so they are doing more design and testing before the expensive part, using increasingly elaborate simulations.