[mgraczyk]

Google and Facebook both use trunk based development for nearly all code at both companies.

This guide advises you to consider trunk based development if your release cycles are less than ~4 weeks. I'd suggest doing it no matter what. The only place where I've run into problems with this was managing very long term hold outs where we wanted to avoid changing user visible behavior. Instead of branches, we maintained literal copies of all the files for multiple years. I don't think revision control is the right place to solve that problem though, because there were no clear service boundaries to decide what things to pin, we just did it in an adhoc way.

[Scubabear68]

I am amazed at how much “process” developers these days have to adhere to, including complicated branching strategies plus a whole lot more. So much time wasted doing busy work.

I have always been happiest in a trunk-based dev model, but in many orgs it is heresy to even mention it.

[dboreham]

Imho this is an emergent property from the fact that most folks don't understand what they're doing. If they did, then every time Mr Dilbert pointy head dude comes up with some nonsense process, they'd explain why it isn't beneficial. Instead most of the time everyone nods. Lawyers don't have crazy people telling them how to write contracts. Doctors don't have people telling them how to saw off legs. Teachers kind of do have dumb people telling them how to teach though.

[tnecniv]

Lawyers do. My dad is winding down his legal career but the bulk of it was spent writing corporate loan contracts. He’d constantly have clients asking him to make “small changes” to the document that either made no sense or were, in fact, large changes that would rob him of his weekend. While his specialty was niche, it was not so niche that appeasing the client for their future business was not important. His clients drove him crazy with this stuff but at least he could bill those hours.

I know less about doctors, but they certainly have people that think they know better and question their course of treatment. Just look at the pandemic and vaccine nonsense. Doctors benefit from supply and demand (artificial or otherwise) meaning that they’re basically always booked up.

Developers have neither of those privileges unless you’re an in demand consultant.

[withinboredom]

That’s because the kids have parents who are developers… /s

[seattle_spring]

Someone on HN loudly proclaimed that requiring a code review before merging was antithetical to "trunk based development." He shared the link in OP a dozen times as "proof", but I couldn't find anything in there suggesting such a thing. I also know both Google and FB require code reviews.

Was the guy just totally full of it? Because honestly I wouldn't touch any "strategy" with a 10 foot pole that discourages pre-merge reviews.

[cassianoleal]

There didn't use to be any mention of pre-merge reviews in that website. In fact, the text in the website used to be pretty emphatic against any branching whatsoever.

I have known and worked with Steve Smith (the only "friends" mentioned in the website [0] - hi Steve! :D ) for years and we had many discussions about the merits of short-lived branches for peer review. Myself and a few others have argued that you can have pretty much all the benefits they were looking for with TBD without the draconian "always push to trunk" rule. It just takes a bit of discipline and communication, but to be honest I think the draconian one needs even more of those if it is to succeed.

I'm happy that the website has been updated since (it's been at least a few months, maybe even a couple years) to acknowledge and "allow" that strategy.

[0] https://trunkbaseddevelopment.com/contributions/

[Kinrany]

Post-merge reviews obviously help with the same goal of having very little work stuck in WIP. But it's a 80/20 kind of goal, not all or nothing. Post-merge reviews are probably only worth it when you can trust the developers to not screw up too much and to broadly agree on quality standards.

[mixmastamyk]

Sounds like BS, the two are orthogonal. Would help if you had a link.

[seattle_spring]

I spent quite a while trying to find the post and comments but came up empty. Am kind of hoping the same person will pop up here, as they seemed extremely passionate about pointing it out.

[ec109685]

How did the hold back end up working out? Was the learning worth the hassle?

[mgraczyk]

Yes for sure. In some sense, I learned more from these holdouts than from anything else I've ever done in my career.

[andix]

If Google and Facebook are doing it, then we need to start doing exactly the same! /s

[gipp]

I think their point is more that the usable scale of teams/codebases is not limited by trunk based development. Which that is pretty ample evidence of.

[andix]

I get that. But aren't we all struggling with complex branching strategies and microservices, because someone told us "that's how Facebook/Google is doing it!"? :D

[mgraczyk]

Probably not, because neither of them have complex branching strategies