[dpark]

> most often, I've noticed developers move to TBD because they don't understand the intricacies of their version control system and how to leverage it for a proper async parallel development workflow.

On what do you base this assertion? I would counter that people are switching because they’ve experienced significant difficulties and that your claims they “don’t understand” version control are unfounded.

You didn’t actually explain how these developers were misusing their version control. You just asserted that they are ignorant because they hold a different opinion.

> And if you're working on a big feature, you have to update your branch frequently with upstream changes. Merges of Doom only happen if you're not following version control best practices.

The problem with this glib statement is that it ignores the cost of these frequent merges. If you’re working on a small team, or your feature branch is only changing code that no one else is changing in the trunk, sure. Merge constantly. It’s probably pretty easy. If you’re working on a large team and others are making changes to the same code in the trunk, this rapidly becomes a massive tax. Merges become more and more difficult as others continue iterating on changes in the trunk unaware of the burden they are placing on you to manually merge on top of your conflicting changes.

I have never seen a long lived feature branch merged successfully back into the trunk without major friction. The typical resolution involves locking everyone else out of the trunk to get the merge in (or doing it over the weekend, for the same effect), and turning off half the tests because they all broke in the giant clusterfuck merge.

The validation risk to long lived feature branches is very high. Tests begin to break as you make deep changes in the feature branch. For simple tests, they might be easy to fix. For more complex tests, you might need the test owner to assist, but they don’t want to, because it’s not their problem. You broke it. Except of course you didn’t. The weeks of conflicting changes broke it.

The cost of divergence is high and grows rapidly with age of the branch. Developers begin cutting corners and plan to “deal with it later” as the merge tax rises, because dealing with the merges slows down the work, making the feature branch even longer lived.

[GVRV]

Well, because if you're using Trunk Based Development, you might as well just take backup snapshots of your code on each commit, right? That's not version control, it's just versions.

For the merge pain part of your argument, I would tell you to have a look at any successful open source project. Does it use TBD? Does it still support a big community of developers, mostly working asynchronously and shipping working software?

Now, if you're working on an internal project, please add in a bit of planning (quick note: a developer's job should not include only writing code), you will be able to ship high quality code without it slowing you down.

I'm irked by TBD because is a shortcut. It trades off deliberate collaboration loss for velocity gain – if that is the tradeoff your team wants to make, maybe you should consider it. But I do not get why experienced engineering leaders suggest using it for all teams.

[dpark]

> Well, because if you're using Trunk Based Development, you might as well just take backup snapshots of your code on each commit, right? That's not version control, it's just versions.

I don’t know what you’re attempting to say here. Versions are literally what version control systems manage.

> For the merge pain part of your argument, I would tell you to have a look at any successful open source project. Does it use TBD? Does it still support a big community of developers, mostly working asynchronously and shipping working software?

I would expect that a huge number of open source projects are using trunk based development. GitHub itself encourages roughly this model and hosts a huge number of projects.

Google supports tens of thousands of engineers on trunk based development in their mono repo. Their justification for this is unsurprisingly to avoid merge pain. So yeah, it can work successfully. Complaints about the way Google manages their checkin/release processes is not what I hear from my friends who work there.

I find it interesting that if you go read about the Linux model (which uses its own model that’s definitely not trunk based development), there’s a big emphasis about getting code integrated into mainline (vs maintaining a custom fork) because the cost of maintaining a custom fork is immense due to constant merges. It’s the exact same issue.

> Now, if you're working on an internal project, please add in a bit of planning (quick note: a developer's job should not include only writing code), you will be able to ship high quality code without it slowing you down.

Please say more here. This is the second time you’ve hand waved and said “better planning”. What exactly does that entail? What planning can an engineer do to make merge conflicts go away? Are you proposing that they plan to just not make conflicting changes in their long lived branches?

> I'm irked by TBD because is a shortcut. It trades off deliberate collaboration loss for velocity gain – if that is the tradeoff your team wants to make, maybe you should consider it. But I do not get why experienced engineering leaders suggest using it for all teams.

The way you say “shortcut” here sounds like you agree it works better in practice but you just don’t like it for some reason. Honestly, the vibe I get from your arguments is that long lived branches would work great if everyone else just wasn’t an idiot.

In my experience the real trade off between a trunk based development model and a long lived branch model is mostly short term pain (felt in the trunk based development model) and long term pain (felt in the long lived branch model). Everyone checking into the trunk causes immediate pain if something bad gets in. On the other hand, it tends to be much quicker to resolve vs long lived branches which can hide bad changes for as long as the branch lives until the final merge to trunk. It’s the exact same trade off for requiring build pass before checkin, or gating on tests for checkin. Deal with this shit now or deal with it later. With long lived branches it’s just much later and the impact of dealing with it so late can be so much higher. (It is also the same trade off faced by “micro repos”. They’re great up until the point that they need to take dependencies on other repos or vice versa, at which point it’s essentially just another way to trade immediate vs delayed-but-increased merge pain.)

Edit: Amusingly, the guy who first proposed GitFlow now also suggests using something simpler if you are doing service development with continuous delivery.