Trunk-based development: the evidence and the tantrums

Few practices have a cleaner evidence base and a messier adoption record. DORA's research program has associated trunk-based development, short-lived branches merged frequently into a shared line, with stronger delivery performance for years, per its capability guide, and the mechanism is the same one running through the batch-size story: small integrations surface conflicts while they are cheap. And yet few review topics reliably generate more heat. The heat is worth diagnosing, because it is rarely about branching.

When a team resists trunk-based work, the resistance usually points at a missing prerequisite, and the prerequisite is the real finding. No feature flags, so incomplete work cannot ship dark, so branches live long by necessity. A slow or flaky test suite, so integration is expensive, so people batch to amortize the pain. A review culture where approval takes days, so short-lived branches are structurally impossible whatever the policy says. Mandating trunk-based development on top of those conditions produces exactly the mess its critics predict, and the critics then reasonably conclude the practice failed. What failed was the order of operations.

So our recommendation is sequenced, not zealous. Fix review latency and test reliability first, land flags second, and then shorten branch lifetimes gradually, measuring integration pain as you go. Most teams that walk that path arrive at something trunk-shaped without a policy ever being announced, which is the best sign. The tradeoff is patience: the sequence takes quarters, and a mandate takes a memo. The reversal condition is real too, though the guide does not name it, so we will: contexts with rare, regulated releases or deeply external contributors (some open source) get less from continuous integration into trunk, and forcing it there is fashion, not evidence. Everywhere else, the data has been boringly consistent for a decade. The fight was never really with the data.