TDD, pairing, trunk-based, no estimates: which practices does the evidence actually back?

Operational overhead of distributed systems is well documented and several public cases of consolidating back to a monolith cite cost; evidence is case studies not controlled data.

Studies of TDD find modest improvements in some internal quality metrics such as coupling and cohesion, with mixed results overall and effects that depend on developer experience.

Pair programming meta-analyses show modest quality gains at higher effort, with effects depending on task complexity and pair expertise; no measurement exists for mobs.

A footnote states it is important to avoid premature decomposition of new systems into services, which can inhibit delivery performance, citing Fowler's MonolithFirst; this is an authorial assertion, not a measured result.

DORA's small-batch findings and defect-per-line research support the direction, but the evidence is correlational and vendor-sourced.

Controlled studies show TDD lowers defect density at some cost in development time; direct measurements of debugging time are scarce.

Survey research such as DORA links reliable test automation with higher delivery confidence and performance, but the direction of causation is not isolated.

Case studies and surveys of mob teams consistently report faster knowledge spread, but no study measures onboarding time against a control.

Journal version of the same experiment: the compiler points to the exact location of a type error, whereas the dynamic system finds it at run time with symptoms that may appear far from the cause, which is why Groovy subjects needed more navigation and more test runs.

DORA data correlate trunk-based development with better delivery metrics and small changes are easier to revert, but the gains are correlational and the team's own numbers are self-reported.

Communication-path growth is the classic Brooks argument and Conway-style case studies support boundaries helping, but there is no controlled measurement of microservices reducing coordination.

At Google the median wait for first reviewer feedback is under an hour for small changes versus about 5 hours for very large ones; overall median review latency is under 4 hours with a median change of 24 lines.

Interpersonal work time differences are real and larger than most experimental effects, but the slowest-to-fastest-quarter ratio is rarely above 4 and the Grant/Sackman 28:1 figure (really 14:1) looks like an outlier; the author cautions that student populations may understate practical variability.

Maintenance is generally estimated to consume well over half of lifecycle effort, though the exact figures are poorly sourced.

Reproducible on this microbenchmark; the gain in real programs depends on how much time hot loops spend in dispatch.

Microservice envy is widely reported; its magnitude is unmeasured.

A description of adoption patterns and taste rather than a measurable benefit claim.

Labour economics and reviews of overtime research show output per hour falls and errors rise after sustained weeks beyond roughly fifty hours, and burnout studies link crunch to attrition.

Review of time-prediction studies finds average error of 20-30% and no general bias, but software projects of at least 100 work hours show a median overrun of about 20%, so large-scope estimates are biased low rather than useless.

The mechanism is direct, and DORA research associates short-lived branches and trunk-based development with higher delivery performance.

Flaky and brittle UI tests are extensively documented in industry reports and flaky-test research, which is why the test pyramid pushes coverage downward.

Incremental re-architecture is widely practiced and documented, but some structural changes are impractical without large rewrites.

Pairing does catch defects as they are written, but pairs cost more person-hours, so 'without slowing' depends on the measure.

Williams' student studies found high post-trial preference, but professional adoption surveys show persistent dislike among many.

A values statement about what counts as excellence.

The SmartBear Cisco field study found defect density per line falling past roughly 200-400 lines per review, though it is a single vendor-run industrial dataset rather than a controlled experiment.

Conflates typing with ahead-of-time compilation; static languages are usually faster, but JIT compilers make dynamic languages competitive and types are only one of several causes.

Scripts (Perl, Python, Rexx, Tcl) took a median 3.1 hours versus 10.0 hours for C, C++ and Java and were half as long, but the author attributes this to built-in associative arrays and the absence of declarations, times were self-reported for the script group, and the result is explicitly limited to the phonecode problem.

Large occupant surveys such as Kim and de Dear find open-plan workers less satisfied, especially on noise and privacy, with no offsetting gain in ease of interaction.

Across 31,000 generated suites on five large Java systems, coverage correlated only low-to-moderately with mutation-detection effectiveness once suite size was controlled, so high coverage does not indicate an effective suite; executing a line does not reveal an error in it.

Six years of survey data show speed and stability are outcomes that enable each other: cluster analysis finds elite performers do significantly better on all four metrics and low performers worse on all, rather than trading throughput for stability.

Re-analysis of 61 experiments (614 subjects) finds the slowest-quarter to fastest-quarter median ratio is typically 2-3x and max/min ratios above 10 are rare, so the 10x spread is an artifact of best-vs-worst comparison; the report does not measure a programmer's own task-to-task variation.

Integration and system tests do catch defects unit tests miss, but relative cost-effectiveness depends on the system and is not well quantified.

Deadline pressure is a documented driver of overtime, but the chain from estimate to crunch is not inevitable.

Incremental funding does reduce exposure, but cancelling early still needs some forecast of what remains.

Dawson and Reid's equivalence studies and later work show sleep loss impairs performance like alcohol and degrades self-assessment.

Netscape, Borland and similar cases support it, but successful rewrites exist, so the harm depends on scale and context.

Comprehension consumes most maintenance effort in studies, supporting the premise; the inference about misjudging old code is plausible but untested.

Systematic review found no general overoptimism in software when small tasks are included, but projects of 100+ hours had a median overrun of about 20%, i.e. more than half of larger projects overran while small tasks were unbiased or overpessimistic.

Independent repetition and reanalysis of Ray et al.'s 729-project study: mislabelled TypeScript files, duplicated bitcoin forks, 36% false-positive bug labels and no multiple-testing correction; only 4 of the 11 claimed language-defect associations survive and even those have exceedingly small effect sizes.

Blind-analysis crossover replication with 21 graduate students found no difference between TDD and incremental test-last in tests written (p=1.00), external quality (p=.82) or productivity (p=.82), with negligible effect sizes, confirming the Oulu baseline experiment.

A decision framework rather than a measurable claim.

Self-reported by experienced practitioners; no study separates the design effect of TDD from the habit it builds.

Widely reported anecdotally; no study measures downstream debt created by high-output individuals.

One documented instance: the famous 28:1 programmer variability figure is wrong (two methodological mistakes, correct value 14:1), rests on 12 subjects, was published in an obscure journal, and kept being quoted after Dickey debunked it in 1981.

Working-memory limits are well established and information hiding has long-standing empirical support for change isolation.

Across 30,737 files in 39 proprietary codebases, Alert (low Code Health) files had 15x the Jira defects of Healthy files and issues took 124% (about 2.2x) longer on average, so 'many times more defects' holds but 'several times longer' overstates the average time effect; observational, CodeScene-customer sample, vendor-authored, causality direction acknowledged as open.

Consistent practitioner anecdote from Fowler, Newman and others, but anecdotes suffer selection bias.

Modular monolith reports from Shopify and Prime Video are positive, but in-process boundaries are known to erode without tooling.

No IDE-level refactoring crosses process or API boundaries; coordinated deploys and versioning are required.

A reframing consistent with debt-interest models but not separately testable.

Interruption studies by Mark and Parnin show substantial resumption cost; the half-day unit is unmeasured.

One large telemetry study reports code output rising far faster than shipped software after agent adoption, but attributing the gap to review is the authors' inference and other bottlenecks (testing, deployment, product decisions) are not separated out.

Supported by a public retraction and by audits of agent-ported code finding unusual numbers of unsafe constructs, but the evidence is anecdotal with no controlled comparison.

Postmortems and case studies link crunch to scope and schedule failures, but publisher deadlines, funding and studio culture also drive it, so planning is one cause among several.

Matches the standard definition of continuous integration as frequent integration to a shared mainline, which tooling alone does not guarantee.

A well-established mechanism used at scale by large web companies, with documented costs in flag management.

Over-specified interaction tests are a documented cause of fragile suites in both practitioner literature and studies of test co-evolution.

Controlled studies of TDD report roughly fifteen to thirty-five percent more initial development time alongside fewer defects, so the slowdown is real but is partly repaid later.

Two Fortune 500 headquarters moved from cubicles to open floors; wearable badges and server logs showed face-to-face time fell 72% (5.8 to 1.7 h per person per day) at the first firm and 67-71% at the second, while emails sent rose 56%, received 20-50% and IM messages 67%; quasi-experiment without a control group, 52 and 100 participants.

Studies find comment-code inconsistency common after change, but comprehension research also shows explanatory comments help readers, so the claim holds for restating comments not all comments.

Prechelt's controlled pattern experiments found patterns help only when their flexibility is needed and otherwise add comprehension cost.

A design heuristic; co-change analysis can detect the pattern but whether merging is right is a judgment.

Inference clearly cuts annotation burden in Go, Rust and TypeScript, but compile times, generics complexity and type-error comprehension remain costs.

Change summaries plausibly cut orientation time, but there is little independent measurement of review speed or defect-finding with AI summaries.

Context switching has measurable cost in general, but the size of the gain from tool consolidation is a vendor claim without independent data.

Patch latency follows directly from lead time; the risk exposure is real though its magnitude varies.

Design damage from test-driven isolation is reported in case studies and the DHH debate, but controlled studies of TDD's design effects are mixed and small.

Follows from the variance finding, but environmental interventions have not been compared head-to-head with hiring in controlled studies.

Test-induced indirection is widely reported in practice and in the DHH debate, but controlled studies of TDD on design quality show small mixed effects.

Reasonable and consistent with practice, but no study compares test-mix strategies against outcomes.

A framing about what counts as success rather than a measurable claim.

Widely reported in practice surveys, but there is no measurement of how often it happens.

Vasco Duarte's project data and some team analyses show story count tracks points closely, but this depends on stories being similarly sized.

DORA's SEM finds SDO performance predicts organisational performance on commercial and non-commercial goals, and elite performers are twice as likely to meet or exceed their organisational performance goals; both sides are self-reported in a cross-sectional survey.

Fatigue-error links are well documented; net negative team progress is a plausible extreme rather than a measured average.

The Gamasutra/IGDA survey analysis found this; it is a single self-reported dataset but no study shows crunch improving outcomes.

Second-system effects are documented, but a rewrite with clearer requirements can succeed.

All indicators (time, test runs, files opened, file switches) favoured the static type system on type-error tasks because the compiler names the location while a run-time failure appears far from the cause; the feedback came from a compiler in a plain text editor, not an in-editor checker, so the claim's in-editor form is an extrapolation.

Review latency is a measured delay in PR studies, but many teams integrate daily with small PRs, so the incompatibility is not absolute.

Reported in pair-programming studies as 'pair pressure', mostly self-reported.

Comments had only 33% relative predictive power for readability judgments, less than blank lines; the authors suggest comments appear where code was already less readable so the two balance out, giving neither strong support for comments nor for treating them as failures.

Scanniello et al. found no difference for debugging, but other comprehension studies found full words help, so results conflict.

Hannay et al.'s meta-analysis found small quality gains and effort increases with high heterogeneity.

Inspection studies report high detection rates under limited review rates; modern lightweight review finds fewer.

A claim about community culture and tone, not a measurable effect.

Surveys at Microsoft and Google rank knowledge transfer among the top benefits of review.

Tests document behaviour but are hard to navigate as documentation; evidence is practitioner opinion.

Well-known data-oriented design result for compute-bound loops; most application code is not compute-bound.

Holds for the toy benchmark; in typical applications I/O, allocation and network dominate so the end-to-end cost is far smaller.

A design-perception claim with no agreed measure.

Evidence that small functions or polymorphism improve maintainability is thin and mixed; readability studies are mostly small.

Flow and TypeScript each detect 60 of 400 sampled public JavaScript bugs (15%, 95% CI 11.5-18.5%), so retrofitted types find a minority of bugs, but the authors stress this is a lower bound (public bugs only, two weak type systems, non-expert annotators) and an engineering manager called a 10% reduction a no-brainer.

Early structural decisions are the costliest to reverse, though the exponential defect-cost curve behind this is overstated.

Controlled studies find no comprehension gain from splitting code into very small methods, though none establishes where the optimum lies.

One vendor dataset shows higher revert rates under ten lines, plausibly from config changes; the pattern has not been replicated.

Besker et al. surveys report roughly a quarter of time self-reported as wasted, but the figures are self-reported and vary widely.

Consistent with migration case studies, though some decompositions of tangled code succeeded with heavy investment.

Plausible; no evidence.

Classification framework.

Engagement is self-reported; no comparative data.

Netflix and Amazon cases support it; there is no evidence about where the threshold lies.

Smaller methods correlate with fewer defects up to a point, but studies find very small, deeply delegating methods hurt comprehension.

Velocity is team-relative by construction; Goodhart effects on normalised points are widely reported.

Fowler's design stamina hypothesis is a hypothesis; consistent with debt-payoff reasoning.

Re-analyses of the classic studies show best-to-worst ratios of ten or more but quartile ratios nearer two to four, so the gap depends on which tail you include.

Follows from undecidability; every practical sound type system is incomplete.

Running partially broken code aids exploration, but gradual typing and IDE tooling narrow the gap.

Tests only cover specified behaviour and cannot see maintainability, scope or hidden coupling; the METR maintainer study cited here supports this, though it is one study on agent-written PRs.

Ensemble and self-consistency effects are well documented for language models, but the size of the review-quality gain rests on one academic paper and vendor reports.

Prompt injection against LLM reviewers is a documented weakness and vendors warn about it themselves, but the specific human-versus-agent comparison comes from a single study.

Review fatigue and the tedium of full-time review are widely reported by practitioners, but there is no measured burnout study specific to this arrangement.

A forecast about how roles will evolve rather than a claim that can be checked against evidence.

The mechanism is plausible and matches practitioner experience, but controlled TDD studies measure defects and productivity rather than coverage gaps, so the size of the effect is not established.

A framing about what trust in a suite means rather than a measurable outcome; partial suites still catch some regressions.

A claim about enjoyment and motivation that varies by person.

The mechanism follows directly from having all needed skills present, and mob case studies report it, but there is no controlled comparison and it depends on the product owner being present too.

Self-reported from one team with the speaker himself saying the card comparison is not proof; no independent measurement of mob throughput exists.

A single group working on one branch has nothing to merge, so this follows by construction and is consistently reported by mob teams.

Lean and queueing theory plus context-switching research support the cost of multitasking and partially done work; the inventory framing is a model rather than a measurement.

A team norm whose necessity cannot be separated from the practice in available evidence.

Plausible by analogy to frequent feedback loops but no study compares retrospective cadence.

Industry surveys such as IGDA's find crunch still common in games with roughly half of respondents reporting it, so the picture is mixed; the video's own survey is small and self-selected.

Surveys find both self-driven and management-driven crunch, and normative pressure makes voluntary overtime hard to separate from expected overtime.

Based on a small informal survey; broader data on company size and hours in software is inconsistent.

A judgment about the nature of the work rather than a measurable claim.

The Knight Capital incident is documented in the SEC order as a repurposed flag plus an incomplete deployment, and flag hygiene guidance exists because of such cases.

Practitioner accounts and DORA both treat fast automated tests as a prerequisite for continuous delivery; synchronous review is one way to meet the merge cadence but not the only one.

The queueing mechanism is sound and widely reported, but evidence is practitioner case studies and the environments bring their own cost and data-seeding work.

Release branches cut from trunk are a standard way to ship versioned products from trunk, so the limit is weaker than stated, though strict version control does reduce the practice's advantages.

DORA surveys associate continuous delivery with lower burnout and higher job satisfaction, but causation is not isolated and this is one team's impression.

Stale-flag debt is well documented and large companies have built tooling specifically to remove dead flags.

A definitional reading of Kent Beck's book rather than an empirical claim.

Practitioner consensus including the Fit author's own retraction supports this, though some teams report value from Gherkin-style specs; no controlled study exists.

Kent Beck's original claim, consistent with cognitive-load arguments against solving and designing at once, but not directly measured.

Practice advice that follows from the definition of refactoring; whether existing tests actually cover the behaviour is case by case.

A judgment about test maintenance trade-offs with no empirical comparison.

The Bernstein, Shore and Lazer intermittent-collaboration experiment found this pattern, though on abstract problem-solving tasks rather than software work.

The left-pad incident and subsequent supply-chain research show deep transitive dependency trees in npm expose projects to removals and malicious updates.

A sociological framing about how practices propagate.

Parkinson's law and Brooks's law have anecdotal and some experimental support for deadline effects, but the ten-versus-hundred example is a single anecdote.

Identifier studies show descriptive names improve comprehension; the specific heuristic about vague suffixes is expert opinion.

Anecdotal from client codebases; no measurement of logging proportion across projects.

Practitioner surveys and case studies report these as the realised motivations, alongside maintainability and operational costs that offset them.

Smaller change sets do carry less risk, but as Fowler notes in the same conversation the distributed system adds integration risk a monolith can test end to end, so the net effect depends.

Architecture erosion studies confirm in-process modules decay, but distributed monoliths show process boundaries get violated too via shared databases and chatty coupling.

Loss of cross-service joins and ACID transactions is intrinsic to the approach and migration literature consistently names data as the main difficulty.

Consistent with Conway's law research and practitioner reports, but it is an expert judgment rather than a measured outcome.

Large GitHub studies found a small defect advantage for static typing that weakened on replication, and bug-detectability studies suggest a type checker catches a minority of real bugs, so the benefit is real but modest.

DORA's own reports find the four keys correlate with organisational performance, so a link exists, but it is indirect and does not say whether features were the right ones.

They are lagging indicators by construction, though teams routinely act on their trends, so the practical limitation is smaller than framed.

A vendor dataset with a product to sell, though independent studies at Google and Microsoft also find review wait time dominates review cycle time.

A generalisation about motivation that varies by team.

Risk-based review routing is plausible and used at large companies, but the benefit here rests on a vendor's product claim with no independent measurement.

Just et al. found mutant detection correlates with real-fault detection, with caveats about mutant representativeness.

A surviving mutant may be an equivalent mutant (e.g. == changed to >= with identical behaviour) rather than a missing test, and manual inspection is needed to tell; the study classified up to 35% of mutants as equivalent, so the either/or omits a third case.

Runtime is the documented adoption barrier; Google's deployment runs mutation analysis only on changed lines for this reason.

Manual inspection is required because automatically determining whether a mutant is equivalent is undecidable, which is why studies fall back on assuming anything the master suite misses is equivalent.

A practitioner hunch; fewer larger tests may run slower per mutant, so the net effect on runtime is unclear.

Achievable for many codebases but costly for legacy or hardware-bound code; coverage-driven tests are often weak, which is the speaker's own point.

AI review tools do produce first-pass comments; how much of the human review they replace is not independently measured.

Controlling for industry, DORA found no evidence that industry affects SDO performance except retail (which did slightly better), including highly regulated financial services and government; organisation size over 5,000 employees did predict lower performance.

Skipped testing in emergency changes is widely reported in incident reviews but not quantified here.