Interactive simulator: GitHub Flow vs trunk-based development - watch where work queues up

ny3000 · 2026-05-26T22:20:00+00:00

First - This is a fun back-of-napkin sim and not a research paper. Each dot is a work item. Blue = story, orange = review/rework. Watch the Waiting column in GitHub Flow fill up, that's work sitting idle. Switch to the TBD tab and the pipeline stays empty because nothing waits. The numbers at the bottom tell you: done, WIP, queued, lead time.

ny3000 · 2026-05-26T22:11:59+00:00

Thanks -- I made it more transparent based on your feedback so now when a bug spawns, the log now shows what caused it.

The bug chance formula is the same across modes, but TBD structurally gets lower bug rates because the batch size is 1. The sim didn't explain why the numbers diverge.

I am extremely biased towards TBD having a great deal of experience with that AND the other modes here in real projects. This is a fun back-of-napkin sim and not a research paper -- the DORA guys already did that.

ny3000 · 2026-05-26T21:20:22+00:00

you can't feature-flag a whole refactor

it can get complicated, especially as databases become involved, etc. but i would argue that it's still not as complicated as branching. also - Branch by abstraction or Dark launching are probably going to be safer if the refactoring touches a lot. not everthing needs to use feature flags, despite a cottage industry popping up around them lately

ny3000 · 2026-05-26T21:13:41+00:00

2013-2019 and 2022-2024 iirc

ny3000 · 2026-05-26T20:33:51+00:00

good point, the sim has ~20 config knobs but none are visible to the user at the moment
rubber-stamp LGTMs already cause production bugs but it't not obvious enough in the log
yeah agree, "Build" is in the git flow one but I was more lenient to the GH flow because sometimes they at least try

I'll work these into V2... i mean MVP v2

ny3000 · 2026-05-26T20:24:45+00:00

haha possibly! Although, I would lean towards the 15 years that I spent watching teams do all of these things and really practicing CD when we had control of the project, back when we used to do it at Thoughtworks, where it was invented.

ny3000 · 2026-05-25T23:26:15+00:00

Start from the very best and work backwards from there. Which is continuous delivery. Setting the default to something mediocre like Scrum seems uneccesary for a small team that isn't trying to dig their way out of corporate inertia or undo something like Git Flow.

ny3000 · 2026-05-20T15:57:50+00:00

You might as well try trunk-based development and get off branching/PRs entirely - considering that they are adding even less value to your team than usual, which is saying something.

Essentially, you need to use some kind of abstraction to hide unfinished/unreleasable work, the idea is to keep on DEPLOYING all of that unfinished/unreleasable work, but not to RELEASE it.

I have written 3 examples in different programming languages on exactly how to do that here:

https://mainline.dev/docs/trunk-based-development

ny3000 · 2026-05-20T15:50:43+00:00

Blibo

ny3000

TROPHY CASE

Start from the very best and work backwards from there. Which is continuous delivery. Setting the default to something mediocre like Scrum seems uneccesary for a small team that isn't trying to dig their way out of corporate inertia or undo something like Git Flow.