Welcome to the new week!

We're searching for simple answers to hard problems. We scroll through social media, getting 10-30 seconds of "life hacks.". Just like in the James Bond movies, the message disappears right after it is read. And that's a good thing, as it'd be more dangerous if we actually try to apply them in practice.

I think we're in times when we're getting more often edutainment rather than actual education. Our dopamine is boosted by taking a dose of those quick answers. We get the feeling, "hey, I just learned something new!". But do we?

The advice-givers usually don't have bad intentions. Most of the time, they believe that's great advice, as it worked in their one or two projects. Sometimes even more, but quite often also in none, as it's more a process of their thought experiments.

The shortness of social media posts or short videos also does not help. To reach a wider audience, it has to be kiss, kiss, bang, bang. And if you believe your message is right, then you should try to reach wide audience, right? When in Rome, do as the Romans do.

But that's a trap. The trap of overselling and changing your message into snake oil: a magical cure for everything. It's even easier to fall into that if you spend too much time thinking about it or have financial incentives.

Martin Fowler, in his great article "Advocate, educator, and authorial stance", wrote:

I see this as part of the difference between an advocate and an educator. The advocate wants the reader to agree with them, they succeed when the reader uses the technique that's being advocated. I prefer the role of an educator, I succeed if the reader makes a well-informed decision, even if the reader chooses a different path to the one that I would choose in their situation. (This also means that if the reader does the exact same thing I would have done, but does it just because "Martin said so ", not understanding the trade-offs properly - then I've failed.)

That's one of those articles I get back quite a lot as a reminder of where I should also be in my work. Am I succeeding? Dunno, you tell me.

What I know, though, is that there are leitmotifs in my bubble that I see as harmful and misleading. Not because they're wrong per se but because of how they're presented. They oversell the idea without explaining to people what they're signing for. And that's dangerous.

Trunk-Based Development

One of those oversold motifs is Trunk-Based Development. One branch to rule them all.

What's Trunk-Based Development? From the DORA website:

There are two main patterns for developer teams to work together using version control. One is to use feature branches, where either a developer or a group of developers create a branch usually from trunk (also known as main or mainline) and then work in isolation on that branch until the feature they are building is complete. When the team considers the feature ready to go, they merge the feature branch back to trunk.

The second pattern is known as trunk-based development, where each developer divides their own work into small batches and merges that work into trunk at least once (and potentially several times) a day. The key difference between these approaches is scope. Feature branches typically involve multiple developers and take days or even weeks of work. In contrast, branches in trunk-based development typically last no more than a few hours, with many developers merging their individual changes into trunk frequently.

The following diagram shows a typical trunk-based development timeline:

A similar definition can be found in other places.

In a nutshell Trunk-Based Development, it's a "just" branching strategy. Focused on minimising the lifetime of changes made outside the main branch. That can be done by either committing directly to the main branch or having some short-living branches.

Clearly, this definition doesn't forbid the branches, reviews, pull requests, etc. Yet most of the time, trunk-based development is shown as the opposite of them. Too often, we're being pushed with absolutes like:

• pull requests are root of all evil,

• just do pair reviews,

• no trunk-based development - no continuous integration,

• pair and mob programming and trunk-based development are the only ways to deliver good and fast.

Don't get me wrong; I like to keep branches short-living, I like to pair, and I'm not a fan of nitpicking in pull request reviews or delivering slowly. I'm all for that, but with the right proportions and embracing that different organisations are on different levels of "process maturity." Not all can just throw away their current practices and turn them upside down, even if the new ones are considered "best practices."

Giving advice is not as simple as:

• do small and short Pull Requests,

• write simple code,

• use trunk-based development.

Those are thank-you-for-nothing pieces of advice that are not actually actionable. All of that represents the outcome of our development process, not the process itself. What does that even mean, short, small, simple? Ask your colleagues; I guess that each person will give a different answer. Applying such simple recipes applied in isolation will not change the overall picture.

I would prefer to see real studies on how to approach organisational evolution, when to do it, and how and when to say "enough is enough". Of course, I don't want reports like the (in)fameous McKinsey report on developer productivity. I don't want to see reports focusing on the differences in the exact code lines or minutes spend metrics. Most of those that I saw are missing the point, not understanding the difference between correlation and causation.

Being in the industry for over 17 years is a privilege. I remember how it looked when I started. Those were days before StackOverflow existed. Weird and dark times. I saw the initial trunk-based development, and I remember why Git Flow and Pull Requests became popular. There was a reason for that.

Gilbert Chesterton wrote about this type of change using the metaphor of a fence:

There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.

So, if we want to throw away the fence of code reviews and pull requests, we should understand why they were created and what problem they're trying to solve.

When I started my career, code repositories weren't even a standard in the industry. Of course, most companies were using some code versioning systems, but not all cared enough. The standard was SVN. Each company had to keep its own system. SVN had a main branch called trunk, thus "The initial trunk-based development," as I call it.

It was a nightmare. SVN didn't have local branches like Git. So you were actually forced to always push your changes to remote. Of course, you could push it to the remote non-main branch, but the branching merging was a nightmare. Quite often, the team had a person who was called to do the merges, as it required a specific craft not to break the main branch...