The benefits of trunk-based development

> Note that the Pull Requests were introduced by the Open Source Software community. It allows core teams to maintain a system and accept contributions from the outside world. The outside world is generally perceived as low-trust. Therefore, we want to verify those contributions. Pull Requests are pretty helpful in that regard. However, in a closed-source corporate setting, the Pull Request model essentially indicates that the team owns the codebase, but it is not allowed to contribute.

I think this is a very lopsided way of looking at pull requests. They are about a lot more than just trust. Reviewing and being reviewed is a great way of learning from colleagues, making common practices gel in a team, and keeping up to date with changes to the codebase. It’s not just a barrier.

> money stuck into the system. It is stuck because the organisation invested considerably in creating all this code on parallel branches. However, as long as this code is not merged into mainline, deployed in production and released to users, it does not generate any revenue. Therefore, it is money stuck in the system. But, because we have less WIP, we create less inventory. As such, we have less invested money stuck in the system.

I’ve been telling people that work in flight should be minimised for a long time, but this is the first time I’ve heard the inventory metaphor and I like it. It’s a similar metaphor to tech debt.

> With trunk-based development teams, managing technical debt becomes a non-issue. It just happens.

Unless it doesn't happen. Issues that are dealt with automatically are those that would break the build, or make tests or linting checks fail; everything else can simply accumulate without anyone "wasting time" on it.

Technical debt is often recognized retroactively (e.g. there is a new foreign customer and not enough time to write thousands of neglected translated labels and messages).

Used trunk-based dev a lot. Not a fan. It sounds good on paper, but in practice, it gets messy fast and code quality is hard to maintain, especially when teams are remote.

What actually works is trunk-based deployments — keep main always deployable, and ship from there. Simple.

PRs, are underrated. They’re great for sharing context. You get inline comments, CI runs, you can test stuff in isolation by spinning up infra, and teammates actually see what’s changing.

Stacked diffs make juggling multiple PRs manageable. And yeah, PR reviews can slow you down, but honestly, I think that's a plus. Slowing down just enough to have another human look at the code pays off more often than not.

I wonder how all these absolutist methodologies really work when you take subjectivity and our general inability to measure anything reliably away? I say this because we've tried all of them after someone read an article on a blog saying it'd solve all our problems. And we always have the same problems afterwards despite people promoting that it solved them. Sometimes even worse ones.

The root cause in my company is we hire the lowest cost outsourcing outfit we can find, which hires inexperienced juniors and pretends they are senior and has a huge staff turnover because who the hell wants to work like that for more than 12 months. But of course changing the repo structure and process will compensate for that.

My observation is that a good engineering team will self-organise a methodology that works. The methodology is unimportant compared to getting a good engineering team. I am fortunate that I work in a small niche pocket in the organisation that has good engineers and has resisted normalising with the process churn of the rest of the organisation.

We run a "dark ages" team really. We were on SVN until 2020-ish, because, well it worked fine for us. Now we're on github on commandment but it is used like SVN. We have light feature branches. Master is always stable. Releases are tagged off master. At no point do we use any other github features not even PRs. CI is makefiles. Push to ECR/S3 by human. Deployment is makefiles. Comms is email because Slack is too distracting and demands immediacy. Issue tracking is a 17 year old JIRA project with a default workflow. We have the lowest defect rate, the lowest time to market and highest ROI per head in the entire org and we don't have or need a platform/sre/devops team supporting us.

We are a disliked because we didn't do anything for over 10 years other than deliver software.

It probably depeds on the kind of software you create, but in our case:

When i add non-trivial code I want others of my team to review it first. When it is on trunk, it gets less easier to refactor as others already might use it. In this sense using a MR is really good way to get some quality checks before it goes to main and needs to be supported (in most cases) indefinitely. Next, we have system tests that i really want to avoid breaking on main and getting EVERYONE stuck.

The problem arises if I keep that branch for more than a week. Merge conflicts get harder, the financial investment is not leveraged, etc etc.

The problem is with long lived branches. This is something you should avoid, you can take it to the extreme, no branches. But extreme is almost never good.

PS CC is really good at rebasing and resolving merge conflicts.

After a couple of decades in the Danish software industry I've come to accept that there is only trunk-based development (COME AT ME!). Feature branches, set releases and so on are fake safety gaps that people add when they don't trust themselves and/or their developers. These days I view it similar to someone who won't deploy changes on fridays because they fear for their weekend. If you're too afraid to deploy on a friday, then you should not be allowed to deploy on a monday. Similarily, if you're not brave enough to push changes to production, then your changes aren't ready.

Of course I don't actually think there is a religion on how to do these things, but I've never seen any particular quality added by people doing quarterly releases from a feature branch. For the most part I think this part at the very beginning of the article explains a lot of the reason as to why that is:

> When we do trunk-based development, the WIP we commit gets used, before any actual user sees it, by our whole team.

In my eyes all of it comes down to management much more than deployment strategies. The disadvantage of feature branching is that it's very easy for management to cut costs on testing. The disadvantage of trunk-based development is that it requires functional teams of people who can actually work together and accept the "norms".

I cannot imagine any advantage of this extreme description of trunk based development over trunk based development with commit stack workflows. You dont have long lived wip but you have draft commits that can mature and be worked on in parallel (also critical for coding agents) constantly auto rebasing on each other. i cannot count the number of bugs that i found before something landed on trunk just because i let “finished” work mature in draft for a bit while i work on the next task. this is especially important if the features have overlap or include ui changes that could have glitches undetectable by tests. similarly you don’t have prs but you have review stacks that are tested and evaluated in any amount of detail required by the context BEFORE they become the new trunk tip. (only fast forward, no merge commits)

It's funny as i get older to see how all these patterns just repeat themselves. When i started out i worked in a team that used subversion and it was by default trunk-based development flow. no code reviews except the single big changeset from all devs. it was how things were done back then by many teams. Then there was a shift towards feature-request-based development with the rise of git and github. trunk-based development was now seen as "unprofessional" in corporate. totally fine and i was there to teach this mind shift.

while the feature-branch-based flow solved some problems it introduced many more like stall branches and out-of-sync code. this became the default as most devs simply weren't aware or had the discipline to merge early and cut their "tickets" to an appropriate size.

mostly for compliance reasons in corporate and big teams i would still advise feature-request-based flow. but as another colleague noted here - it slows you down and if it's a one or two people shop / product you will reap more benefits by doing basic trunk-based flow.

After having worked four years with trunk based development and enjoying it very much, I worked on a project were it was required to have one branch per feature for review purposes. It caused lots of delays, temporary work arounds, merge conflicts, moving changes between branches, bugs being introduced, due to reviews being delayed. I got the impression it made development twice as slow and did not improve code quality.

I'm a big fan of trunk based development in the Churchillian sense. It's the worst form of development, except for all the others.

I don't think it's for every project, or even every feature in a given project. But there's a niche it works best for, and that niche happens to represent a massive percentage of all software engineering.

The niche is, you're building a web app. It's some shitty Web 8.0 version of a Craigslist or something. No one wants to pay for formalized testing. No one really wants to spend a lot of time on quality. Arguably it's not that important to users. The year is Enshittified 2030 and they're lucky if they can even log into their online banking, let alone slide into someone's DMs on your platform.

What's the solution? TBH it's not tripling down on good engineering process. (Don't get me wrong, good engineering process absolutely has a role, I'm merely suggesting that as you move from flight control software to online classifieds to your neighbor's recipe blog, that role diminishes in favor of less formal feedback.) The solution is radically forcing the code into the light of day in front of people who can say or do something about the biggest problems. The minor bugs will probably slip through this net, but the really nasty ones WILL get worked out if people on your team have to deal with them first, followed by an 'insider' circle of users, finally followed by the general public.

That translates to certain buzzwords actually representing great ideas in this type of development, such as: feature flags, CI, pilot rollouts, and... trunk-based development.

Just get the code/feature out in front of a couple people who matter, as early as the day it was written, and keep expanding until you're public.

What they are describing as "Trunk-Based Development" seems a little extreme, and frankly, I'm not sure how achievable it is. Generally, when I've seen/implemented TBD it has involved Pull Requests and code reviews (they seem to imply it shouldn't). With their definition, I think a few issues arise: * Even if you think you can have high quality without PRs, in many industries, it's part of security/compliance. * They say that PRs undermine shared ownership, when actually, PRs done right can enable shared ownership (yes, I can't just merge whatever I want, but also, I get to help ensure no one merges whatever they want).

They also say that "no branches are created". In reality, I don't see how you do any modern development without branches. If anything, contributors need a local branch that is then merged to the trunk (unless, somehow, everyone is live-editing the main branch?). The idea of TBD is just to have smaller, short-lived branches that are frequently merged into main (very doable with pull requests).

> Note that the Pull Requests were introduced by the Open Source Software community.

"Pull requests" by that name maybe. But code reviews existed way before that. As soon as code was written, programmers started to ask for peer reviews of their code.

- Design and code inspections to reduce errors in program development. 31 December 1976. https://ieeexplore.ieee.org/document/5388086

But I guess that today's programmers think that software engineering was created in 2010.