I Commited to Main

Hi,

I committed to main. Just like that 🫢

, you’re likely to have one of two reactions:

“So what? Don’t bore me with that!”
or

“WTF? YOU CAN’T DO THAT!”

If you belong to the first category: Cool! Either you’re not live yet and have the freedom to develop trunk-based, or your organization is so advanced with automation and the DevOps mindset that you can develop trunk-based too.

Everything’s cool! Nothing to see here. See you in the next newsletter!

But… if you’re in the second category. If your neck hairs stood up while reading. Then I have something for you.

In my first job, we were 10 backend developers

We had to synchronize our work. and of course, there were peer reviews. It was too painful when the trunk is broken. It held up the whole team.

So, there was a simple, fundamental rule: Every change must be reviewed before it goes into the trunk.

Easy.

1. Take ticket in progress
2. Pull trunk
3. Create branch
4. Change code
5. Push branch
6. Open pull request
7. Wait for pipeline
8. Set ticket in review
9. Wait for peer review
10. Implement feedback
11. Wait for peer review
12. (repeat)
13. Merge
14. Move ticket to done.

Easy.

It’s just stupid if I want to quickly fix a typo in the documentation.

1. Pull trunk
2. Create branch
3. Fix typo
4. Push branch
5. Open pull request
6. (Posthumously) create ticket
7. Set ticket in review
8. Wait for peer review
9. Merge
10. Move ticket to done.

And all that just for a small typo?

Meh.

I simply didn’t make such changes. Or at least not that detailed. Maybe I just included them in an existing branch.

But sometimes this branch was never merged. So the typo fix wasn’t either. But whatever 🤷‍♂️

Does this workflow sound familiar?

It’s not like I made this up. That’s how I worked for a long time. And that’s how I recently worked with a client.

The result, however, is that I stopped making small, trivial improvements. And that’s a pity.

Just making the world a little bit better. Without dogmatic effort. Would be nice if that’s possible.

With Ship / Show / Ask there’s a pattern you can adopt today

The actual problem lies in the dogmatic adherence to the rule “Everything must be reviewed”.

Rouan Wilsenach published an article titled Ship / Show / Ask on Martin Fowler’s blog in 2021.

Essentially, it’s about the same problem.

His suggestion is totally trivial. Let’s just deviate from the rule.

Give developers back the responsibility to judge whether their change needs a review or not. Or are the automated checks enough? Maybe. The developer should know.

And that’s why he proposes three variants:

Ship : Commit directly to the trunk. To fix a typo we don’t need a process.
Show : Merge right after automated tests, without approval. If there are change requests, then just open a new PR.
Ask: As we know it. We wait for approval for our change.

The interesting thing about this idea is that the individual developer assesses how they want to handle it. For one, it might be too risky to commit directly to the trunk. Then it’s completely okay to wait for approval first. Nothing stops the developer from doing so. Ultimately, the individual developer remains fully responsible. If they make a mistake, they must learn from it.

But we no longer bog ourselves down with dogmatic processes for trivial changes.

A good idea. Why not suggest it to your team!

Rule the Backend,

~ Marcus