How far left should verification move, and which checks genuinely cannot be shifted earlier?

## The question behind the question An interviewer asking this is not testing whether you like shift-left. They are testing whether you treat it as a slogan or as an investment with a shape — rising benefit at first, then flattening, then negative. A lead who cannot name the flattening point will over-buy analysis with other people's hours. ## A test for whether a check should move left Three conditions, all of which have to hold: 1. **The defect class exists in the earlier artefact.** Ambiguity, contradiction, missing cases and an unstated boundary are all present in a requirement, so reviewing a requirement genuinely finds them. A race between two components does not exist in prose, and a review that claims to find one is guessing. 2. **The earlier artefact is stable enough to be worth inspecting.** Analysis performed on a requirement that will be rewritten next month is inventory that spoils. Under high scope churn, the same hours buy more later than earlier. 3. **The hours are affordable at that moment.** A review pulls several people into the same room simultaneously; that is the most expensive form of verification per finding, and it competes with everything else those people could do. When all three hold, moving the check left is close to free money. When the second fails, you have built an early-analysis backlog you will discard. When the third fails, you have a standing meeting that people attend and stop reading for. ## What genuinely cannot move - **Emergent behaviour under real conditions.** Concurrency, contention, data volume, cache behaviour, timeouts under real latency: these exist only in a running system with realistic load and data. A design review can predict a risk and demand a mitigation; it cannot tell you the mitigation works. - **Systems you do not control.** A third-party service's real quirks, rate limits and undocumented behaviours are discovered against the real thing. An agreed interface description keeps you honest about shape; it says nothing about what that vendor actually does at their peak hour. - **How real users actually work.** Site staff will type a date in a format nobody in the review considered, and will keep two windows open in ways the design assumed impossible. - **The cumulative effect of many correct decisions.** Every rule can be individually right while the assembled workflow is unusable or slow. Some signals only exist after release; the discipline for extracting those is a separate practice area, and the honest answer names the boundary rather than claiming shift-left covers it. ## The worked case A clinical-trial data capture programme shifts hard left: every requirement reviewed by a group of four, examples agreed for each rule, an interface agreement between the visit form and the participant-status service, developer-owned checks running in a 27-minute build pack. The defect profile changes exactly as promised — requirement defects rise sharply, post-build defects fall. Then two things happen. First, the sponsor re-scopes the protocol and roughly a third of the reviewed requirements are rewritten; the review effort spent on them is gone. Second, the highest-severity incident of the release is a stale-cache read: under 40 concurrent sites the status projection lags far enough that the eligibility banner shows *enrolled* for withdrawn participants and the adverse-event section unlocks. Every early artefact was consistent with that behaviour — the requirement was reviewed, the interface was agreed, the developer-owned checks were green — because the defect only exists at a concurrency the earlier artefacts do not describe. The correct reading is not that shift-left failed. It is that shift-left bought the requirement-defect reduction it promised, and bought nothing at all against an emergent one, and a lead should have known which of the two the release's biggest risk was. ## Buying the right amount - **Front-load asymmetrically.** Deep early review on the areas where a wrong requirement is expensive or irreversible — data integrity, regulated behaviour, anything migrating stored data — and a lighter touch elsewhere. Uniform depth is the tell of a process applied by ritual. - **Keep early work perishable-aware.** In high-churn areas, review just before build rather than months ahead. - **Preserve later capability deliberately.** If shifting left is used to justify deleting integrated and exploratory work, the programme has traded a known cost for an unmeasured risk. - **Watch the cycle-time signal.** If time from idea to build lengthens while post-build defects stay flat, the front end has become a gate. ## On the cost argument The usual justification is that defects cost more the later they are found. The direction is widely accepted; the specific multipliers are contested and rest on old and narrow evidence. At principal level that distinction matters: it justifies *a* shift, not *any* shift, and it does not tell you where the curve flattens for your programme. The measurable local version — how much rework each late requirement defect actually caused here, over the last few releases — is a better basis for an investment decision than a quoted number from someone else's projects.