🎯 Why review at all 2:40
Before anything else, a team has to answer a question almost nobody states explicitly: what do we want code review to achieve — and have we agreed what good design and good code even look like? The 2012 team's answers were specific.
| Goal | Why it applied to them |
|---|---|
| Mentoring and learning | Novice team; reading each other's code was the main teaching channel |
| Shared knowledge, collective ownership | Six engineers responsible for twenty-something applications; nobody touched all of them |
| Readability and maintainability | "Can we read this as a novel? Do we have the right abstractions at the right levels?" |
| Design consistency | His own stated mistake: finding design problems in review is far too late — design workshops belong before the work starts |
🚫 Two bad reasons 6:10
Two justifications come up in every discussion of code review, and he rejects both.
| Reason given | Response |
|---|---|
| "We need it for the four-eyes principle" (mostly regulated industries) | Quality theatre. It slows everything down for little added value beyond reassuring auditors that boxes are ticked — and process gates drive down quality. It also signals a huge trust problem |
| "I don't trust my own code" | That is a request for an illusion of control, not security. It usually means legacy code nobody understands, or a blaming culture — a cultural and systemic problem, and no process fixes it |
On regulation specifically, he draws a distinction worth keeping: an organisation's approach to regulation is not regulation. Most regulation asks do you do what you say you do, and the strictest versions ask for two sets of eyes and an audit trail. Pair or ensemble programming plus continuous delivery satisfies both — two people saw it, and the pipeline recorded it.
⛔ What review must never be 9:23
| Anti-pattern | Why it is corrosive |
|---|---|
| An exercise of power | Asynchronous tooling makes hierarchy easy: only leads, seniors or architects review. Review should be true peer review, everyone reviewing everyone |
| Assigned to untrained seniors | Technical seniority is not mentoring skill. He describes one mandatory reviewer with poor written communication; leadership knew and did not act — and the team lost engineers |
| Judged by who wrote the code | Measurable bias; see below |
| Blaming and harming | Without a mechanism to curate and train reviewers, bias and abuse are inevitable. A reviewer needs to listen and reflect without judgment |
| A gate | Gates introduce delay and correlate negatively with quality |
| Mandatory | It is a team's choice. Running reviews does not make you mature, and skipping them does not make you a ragtag bunch |
His counter-example: a product organisation with high quality standards that ran reviews only on bug fixes, because that is where the risk lives — and those bugs were race conditions that took a day to reproduce.
⚖️ The bias evidence 11:11
He cites the PeerJ Computer Science study on pull-request acceptance — the largest dataset of its kind at the time, covering GitHub contributions by identifiable women and men. The finding is not subtle:
| Group | PR acceptance rate |
|---|---|
| Identifiable as women | 58% |
| Identifiable as men | 61% |
| Women with gender-neutral profiles | 70% |
| Men with gender-neutral profiles | 65% |
| Overall (outsider vs insider effects aside) | 78.7% women vs 74.6% men |
🏦 The team in 2012 14:50
A technical coaching engagement with a fellow coach, inside a large central player in the finance industry, to raise the engineering skill of a novice team of six responsible for twenty-something applications. What they found:
| Situation | Response |
|---|---|
| No version control at all | Subversion — deliberately, because the local/remote split of Git was a bridge too far for a team that had never used VCS |
| Branching awkward in SVN | No branches: everyone commits straight to remote mainline |
| Novice team, needed mentoring | Pair programming was rejected — with a micromanagement history, someone watching over your shoulder felt like surveillance |
| So no pairing | Code review as the next best mentoring mechanism, plus a team commitment that every change is covered by an automated test |
| Nearly no process | Kanban board where a ticket is a whole feature, not a task — which caps feature size by construction |
🧩 Two key ideas 18:26
| Idea | Mechanism |
|---|---|
| 1. Make review a continuous process | A to review column on the kanban board. Whenever someone finishes work — or at the start of the day or afternoon — they check that column first and review what is waiting |
| 2. Stop review being definitive for release | Review is not a go/no-go decision. Releasability is decided by the deployment pipeline, not by a reviewer |
The units are the part most people miss:
| Unit | What it is |
|---|---|
| Unit of work | The feature (one ticket) |
| Unit of integration | The commit — not the feature, as with feature branching or PRs |
| Unit of release | A commit or a series of commits; the release decision was manual (continuous delivery, not deployment) |
He flags a fair objection: others who tried a to review column found it became a gate in practice, and going slow "for safety" created dysfunction. What made the difference here is that the feature was already growing on mainline, commit by commit, while the review happened over the finished feature — so the column tracked attention, not permission.
👥 One rule, true peer review 20:56
Exactly one rule existed: nobody reviews code they were involved in writing. There was no rule about who may review whom — seniors reviewed seniors and juniors, juniors reviewed juniors and seniors.
🚀 Unreviewed code in production 22:13
Now the consequence that makes people uncomfortable, stated plainly: reviewed and unreviewed code sat side by side on mainline, and every commit that passed the whole deployment pipeline could reach production before the feature was finished and before the review happened.
| Objection | His answer |
|---|---|
| "That risks bad quality in production" | Yes — and it happened many times. But bad quality is not a bug |
| "So bugs ship?" | They ship regardless. Protection comes from automated tests, acceptance tests, exploratory "peer testing" by someone not involved, and static analysis that breaks the build |
| "Then why review at all?" | To raise quality, which raises speed of change — and speed of change is what reduces time to market |
The social contract that made it work: every commit gets reviewed at some point, and any issue raised in review is handled at the highest priority, so low quality leaves production at the next release.
🐞 Reviews do not catch bugs 23:49
His support is experiential rather than statistical — the number of obvious bugs detected in production after a code review is "numerous" — but it lines up with the practitioner consensus that line-by-line reading is a weak detector for anything except surface-level mistakes. What review does well is the thing the metrics never capture: shared understanding, agreed abstractions, and mentoring.
📉 Transaction cost and Little's law 26:30
This is the theoretical core, borrowed from lean manufacturing. Transaction cost is the cost of sending a batch of work to the next stage; the higher it is, the more inventory piles up in front of that stage. Order goods online and pay €3 delivery: you do not order a single €1 item — you batch, to amortise the cost.
| Step | Consequence |
|---|---|
| 10 minutes to make a change, 2 hours waiting for review | The change waits for 92% of its lead time — review is expensive |
| Expensive review | You ask for it less often, and so you batch changes |
| Batching | No small incremental steps, no refactoring, technical debt not paid back |
| Waiting with nothing to do | Uncomfortable — people start new work while old work is unfinished |
| More work in progress | By Little's law: more WIP → more delay → longer lead time → slower feedback |
| Slower feedback | Learning decelerates, teams get risk-averse, innovation flattens into conservative solutions |
📈 What they gained 30:21
With the review happening after commits had already passed the pipeline, the transaction cost was close to zero, and each consequence follows from that single fact:
| Because… | They got… |
|---|---|
| Review had no impact on lead time | No incentive to batch; small incremental steps and refactoring happened naturally |
| Nobody waited for a reviewer | No new work started just to feel productive; one feature at a time, start to finish; far less context switching |
| Lower WIP, by Little's law | Shorter lead time and time to market |
| Production feedback before review | More experiments against real user behaviour, and features nobody used could be dropped unread |
| No pressure to "fix it later" | Time for a proper rethink when the design turned out wrong; no corner-cutting, no technical debt spiral |
| Continuous delivery, flags, fast pipeline | Mean time to recover measured in minutes, sometimes an hour |
He is explicit that bugs in production are not the end of the world, and that 100% coverage will not prevent them because users behave unpredictably. What matters is a process that gets you out of instability quickly — which is exactly what continuous delivery buys.
👀 Four eyes, without the gate 36:23
For regulated contexts that genuinely require two people to have seen the change, the recommended implementation is not a review gate but a different working mode:
| Practice | How it satisfies four eyes |
|---|---|
| Pair programming | Two people read the code before it is committed; the pair signs off at commit time and tags the change with both engineers' identifiers |
| Team / ensemble programming | Same effect with the whole team in the room |
| Continuous delivery | Provides the audit trail: what was deployed, when, by whom, with which tests |
He is careful about the claim: he has not verified this in finance, gambling or healthcare himself, but reports it is a valid implementation used in those industries. And he is clear on the ranking — pair and ensemble programming are superior delivery options; non-blocking review is what you adopt when they are a cultural stretch.
🏥 The regulated-industry gotcha 36:38
The one place he concedes real friction: healthcare, where a code review gate before production is mandated. His unverified proposal, offered as an idea rather than advice: run non-blocking reviews everywhere, and add a separate system that verifies all reviews happened before the production gate — the gate moves from "human reads the code" to "the record shows every change was reviewed", which is what the regulation actually asks for.
🤖 Agents, trust, and accountability 41:57
The best question of the Q&A, and the reason this 2012 case study is worth reading in 2026: how does this model hold when the code was never written or read by a human?
His reasoning is deliberately conservative and worth taking seriously:
- Trust boundaries are the same problem as subcontractors. Either they are part of staff, with the same trust as any colleague, or they are outsiders and you check what comes in — the open-source model.
- Agents cannot hold responsibility because they are not accountable entities. Responsibility stays with the human who prompted the change.
- The medical analogy: doctors use AI, but they make the diagnosis. He is surprised at how much generated code is accepted blindly.
- Regulation is arriving: under the EU AI Act he expects personal liability to land on the CTO — the same argument Anthropic's article makes from the other side, with "whoever prompted it owns it".
🧱 Where this does not fit 49:58
| Question from the floor | His answer |
|---|---|
| Does it scale to 100 developers across time zones? | The HP LaserJet firmware case is the reference: ~400 engineers across the USA, Brazil and India, on embedded firmware, with a dramatic increase in release frequency. Team size is not the blocker |
| Where is the practical ceiling? | Paul Hammant (trunkbaseddevelopment.com) holds that committing straight to mainline works up to teams of about 100; beyond that you need something like PRs or Google's internal model |
| How do you stop a review backlog growing? | WIP limits on the review column. One team let reviews fill the column, then spent a session clearing it and set the limit to one — and simply had to work through it |
| Should juniors touch core components? | Not via review gates — via pairing. Juniors learn more, and feel more productive and more belonging, from pairing than from review, and you still have two people in the room |
| Which release candidate goes to production? | Only the latest one that passed the pipeline — and ensure no cross-system dependencies so each deploys independently |
He is honest about the sample: he has managed this once, with that team, and calls it "a very hard sell". He also reminds the room that pairing a junior properly costs a senior six months of full-time attention — which is why organisations reach for review instead, and then mistake the review's cheapness for effectiveness.
✅ Claims checked
| Claim | Verdict | Evidence |
|---|---|---|
| He wrote the case study up only after Dave Farley asked for an article | Correct | His article, ThinkingLabs, 2 May 2023, credits "Dave Farley for nudging me to write this article" |
| The term "non-blocking code reviews" came from Martin Mortensen's 2020 work | Correct — name garbled in the talk | Article bibliography: Optimizing the software development process for continuous integration and flow of work, Martin Mortensen (the talk says "Martin Mortonson") |
| Deming: systemic problems are created by leadership and must be fixed by leadership | Correct in substance | Out of the Crisis; the talk paraphrases rather than quotes |
| A PeerJ study found gender bias in pull-request acceptance | Correct | Terrell et al., "Gender differences and bias in open source", PeerJ Computer Science; preprint 2016, published 1 May 2017 (the talk says 2016) |
| Identifiable women: 58% acceptance vs 61% for identifiable men; gender-neutral profiles higher | Correct | 58% / 61%; neutral-profile women 70% vs neutral-profile men 65%; overall 78.7% vs 74.6% |
| Accelerate found both peer-reviewing and non-reviewing teams outperform external approval | Correct | The book: "Teams that reported no approval process or used peer review achieved higher software delivery performance… teams that required approval by an external body achieved lower performance" |
| Process gates drive down quality | His claim, with research direction | Consistent with the Accelerate finding above; stated more absolutely in the talk than the evidence supports |
| Code review does not catch bugs | Contested framing | His position, supported by experience, not by a cited study. Review is a weak detector for subtle defects, but the claim is deliberately absolute |
| HP LaserJet: ~400 engineers, three continents, embedded firmware, big release-frequency gain | Substantially correct | HP LaserJet FutureSmart firmware division: 400 people across the USA, Brazil and India; the transformation is documented by Gary Gruver. The specific "per month → per day" figure in the talk is not confirmed in the sources checked |
| Paul Hammant: committing to mainline works up to ~100 people | Attributed position | Paul Hammant maintains trunkbaseddevelopment.com; the specific ~100 threshold is quoted from him by the speaker, not verified at source here |
| EU AI Act puts personal liability on the CTO | His interpretation | His expectation, stated as such; liability allocation depends on jurisdiction and role |
| One release candidate at a time, no cross-system dependencies | Consistent | Matches continuous delivery practice; deploy only the latest pipeline-green candidate |
Basis note. Built from the full 1:00:41 recording, including the Q&A. Every citation was checked against the primary source: the ThinkingLabs article (which also names Mortensen correctly), the PeerJ paper's published figures, and the Accelerate text. The talk's own case-study numbers are unaudited experience, and are presented as such.
🔑 Key takeaways
- Decide what review is for before you run it. Mentoring, shared context and readability — not style, and not design, which review discovers far too late.
- Formatting belongs to the linter. Every stylistic argument a human review spends is credibility burned on something a build should have caught.
- Two reasons to distrust: four-eyes compliance is theatre, and "I don't trust my code" is a cultural problem no process will fix.
- Make review continuous, not terminal. A
to reviewcolumn checked before starting new work turns review into a rolling habit instead of a queue. - Stop review deciding releasability. Releasability belongs to the pipeline; review belongs to quality and understanding.
- Unit of work ≠ unit of integration. Work in features, integrate in commits — that is what keeps the trunk moving and features small.
- One rule is enough: nobody reviews their own code. No hierarchy, and juniors review seniors — the outsider questions are the ones insiders cannot ask.
- Reviews do not catch bugs; tests, exploratory testing and static analysis do. Review raises quality, and quality raises speed of change.
- Transaction cost is the hidden design parameter. A 10-minute change waiting two hours for review spends 92% of its lead time waiting — and teaches everyone to batch.
- Little's law closes the loop: waiting breeds parallel work, parallel work raises WIP, WIP raises lead time, and late feedback kills learning and appetite for change.
- Production feedback before review is a feature, not a risk: if nobody uses the thing, the right response is deleting it, not reviewing it.
- Build the compliance evidence, not the queue. Audit trails satisfy four eyes; gates only satisfy calendars.
- Pairing beats reviewing for teaching — review is what you use when pairing is a cultural stretch, not the ideal.
- With agents, accountability does not transfer. The human who prompted it owns it; a model cannot be responsible, so "can you sleep at night" remains the actual test.
🔗 Resources
- The talk — Thierry de Pauw, "Non-Blocking Continuous Code Reviews, a Case Study", NDC Oslo 2026, 1:00:41
- The written case study — ThinkingLabs, 2 May 2023 (the article's bibliography credits Martin Mortensen and Dave Farley)
- Continuous Code Review — trunkbaseddevelopment.com, Paul Hammant
- Terrell et al., "Gender differences and bias in open source: pull request acceptance of women versus men", PeerJ Computer Science, 2017
- Forsgren, Humble, Kim, Accelerate — the approval-process findings quoted above
- Gary Gruver, A Practical Approach to Large-Scale Agile Development — the HP LaserJet FutureSmart case
- Related deep dive: How Anthropic reviews code at agent volume — the same question, answered with more gates and more machines