Getting past the bouncer

Spend any amount of time reading posts on LinkedIn from techfluencers (is that a word yet?) at the moment and the debate about how to manage integration will come up pretty quickly.

The idea of a pull request (or change request) is embedded into the way almost every engineering team works now. But how they get merged in can vary wildly!

A lot of teams have a process where a PR can’t be merged until it’s been reviewed by at least one other person. This is a great way to catch bugs and make sure that the code is up to scratch, but it can also be a bottleneck. I liken it to a bouncer at a club. They’re there to make sure that the right people get in, but if they’re too strict then the party never gets started.

The other issue with the bouncer, is they’ll cut you in if you ask nicely. In the same way, if you’re in a hurry to get a feature out, you can ask the reviewer to give you a free pass.

If everyone thinks that everyone in the club has been vetted by the bouncer, then it feels like only the people that passed the vibe test got through. But then you don’t know how many of them are actually just friends of the bouncer. Or told the bouncer they forgot their phone.

Instead, we’ve adopted a true continuous integration approach. We have a suite of tests that run automatically when a PR is opened, and if they pass then the PR can be merged. This means that we can get features out quickly, and we can be confident that they’re not going to break anything.

But wait, that’s crazy?

We are still checking the PRs – but sometimes it happens after it’s merged. Feedback should be continous and everything can always be improved. It’s up to everyone to keep an eye on the codebase and make sure that it’s in good shape. The tests make sure that it works, the human check is to make sure that it’s going to be maintainable.

This massively speeds up how quickly we can work. Intercom’s CTO wrote an article Shipping is your company’s heartbeat:

Shipping unlocks a feedback loop that confirms or challenges those assumptions. It makes new things possible for your customers, and gives you the opportunity to focus on the next thing.

Ship, show, ask

Margin Fowler wrote an article a couple of years ago about Ship / Show / Ask.

Ship/Show/Ask is a branching strategy that combines the features of Pull Requests with the ability to keep shipping changes. Changes are categorized as either Ship (merge into mainline without review), Show (open a pull request for review, but merge into mainline immediately), or Ask (open a pull request for discussion before merging).

Each person on the team decides what’s appropriate for the change they’re making. Spelling mistake? Ship it. New feature? Show it. Big refactor? Ask about it.

Using this model has rapidly sped up our development process, and we’re able to get features out to our clients and other Thinkers faster than ever before.