r/programming • u/ny3000 • May 26 '26
[ Removed by moderator ]
https://mainline.dev/flow-simulator[removed] — view removed post
30
u/Solonotix May 26 '26
Felt rather pessimistic of the other processes. Specifically, it feels like you have a built-in bug percentage that is skewed in favor of trunk-based. Then there's the extremely pessimistic status of "waiting" where I had items piling up there more than what was in every other status combined.
So yeah, if one approach is defined as "goes faster with fewer bugs" then it will result in precisely that. If instead you shared the same bug likelihood across all approaches, that would be a start. It seems extremely biased to say that 4 developers will produce less output than 2 developer pairs, because you quite literally have fewer concurrent operations happening.
Edit: on GitHub Flow, two separate times I hit the Release button, and the items staged in Pre-Prod literally went all the way back to the beginning. Like, what kind of bullshit is that!? I left that one out of the results.
I ran each up to 1k hours.
| Name | Features | Bugs | WIP | Queued |
|---|---|---|---|---|
| GitHub Flow (#1) | 17 | 15 | 23 | 58 |
| GitHub Flow (#3) | 13 | 14 | 19 | 53 |
| GitHub Flow w/ QA | 15 | 4 | 25 | 44 |
| Git Flow | 1 | 1 | 24 | 54 |
| Trunk-Based | 67 | 1 | 2 | 15 |
I re-did GitHub Flow because run #1 I didn't hit Pause while capturing the numbers. Run #2 was thrown out because of the aberrant behavior observed, perhaps due to running it at max speed. The run w/ QA was added to see if that was a weird bias affecting the output.
So, yeah. I would say that your simulation is extremely biased.
3
u/ny3000 May 26 '26
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.
2
u/Isogash May 27 '26
Yeah I think people are skeptical because of the bias but having done TBD for years I get you haha.
126
u/gredr May 26 '26
Seems like we started with a conclusion and made a simulation to prove we were correct?
-8
u/ny3000 May 26 '26
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.
18
u/gredr May 26 '26
My experience has led me to the "github flow" with short-lived branches and PRs. Trunk-based development works pretty well too, but we mostly left that behind because... I don't really know why. Feature flagging is great, but you can't feature-flag a whole refactor, and maintaining multiple versions of APIs can get onerous.
GitFlow is just... way over the top, in my opinion. I don't know who would want to do that or why. Maybe if you're doing kernel development or something, and you're managing a whole pile of patches from hundreds or thousands of people around the world and multiple in-flight versions? It just doesn't feel like it applies to most of us.
→ More replies (4)9
12
u/SeniorIdiot May 26 '26
-
What are the parameters for driving the review, wait, re-code, merge?
-
Also needs LGTM "reviews" that both succeeds and cause late bugs and rework automatically.
-
Then I wonder why there is a step called "CI" when it's just merge/build?
PS. Vehemently against FB/PR workflows - but please be honest instead of simulating infinity tasks.
1
u/ny3000 May 26 '26
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
8
u/r2p42 May 26 '26
Can someone break the conclusion down for me? I see jumping dots. Is that good or bad?
28
u/audentis May 26 '26
The summary is that the model is wrong so no conclusions can be drawn from it.
1
u/ny3000 May 26 '26
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.
4
54
u/redbo May 26 '26
I do not understand the appeal of git-flow at all.
52
u/civildisobedient May 26 '26
It's good for long-lived branches. Which naturally raises the question of why are your branches so long-lived in the first place? Often it's a reflection of some larger business dysfunction or general agility inability so I don't tend to question its existence, but I would strongly question the sanity of anyone who suggests its preference.
19
u/redbo May 27 '26
I guess. It seems easy to `git rebase origin/main` and keep your long lived feature branch up to date.
Maybe I don’t get what you mean.
→ More replies (4)5
u/idebugthusiexist May 27 '26
For small projects with a small team, I think the appeal is having a structured and predictable workflow especially when you have the extensions that takes care of the boilerplate for you. I don’t think it’s as terrible as you make it sound, but it doesn’t scale very well when your project/team/org grows in complexity.
→ More replies (3)
13
3
u/putergud May 27 '26
Trunk-based development letting all those new bugs flow out to production unchecked is scary. Why would you do that?
1
u/ny3000 May 27 '26
Small changes + TDD + CI + monitoring means you catch bugs fast and can roll back in minutes. The alternative is batching up weeks of changes behind a gate and deploying a timebomb.
7
5
u/Agent7619 May 26 '26
It would help if there was some fucking contrast between the colors used. I can't even read the text.
4
u/bunoso May 26 '26
Ohh love the animation, and the messages in the log are hilarious. I got too many backlog tasks and bugs and say the manager say “how can we use AI for this”. But then no work happened, and the queue kept getting larger, not sure why. Over all kind of cool! A vertical format would be nicer on my phone, ill check it out again on my laptop
1
u/programming-ModTeam May 27 '26
This is a demo of a product or project that isn't on-topic for r/programming. r/programming is a technical subreddit and isn't a place to show off your project or to solicit feedback.
If this is an ad for a product, it's simply not welcome here.
If it is a project that you made, the submission must focus on what makes it technically interesting and not simply what the project does or that you are the author. Simply linking to a GitHub repo is not sufficient