Don’t be Desmond, or How experimenting with Trunk Based Development increased team trust

Alasdair Parker
Jun 7 · 6 min read
Desmond pushing the button


When the Wolves team was put together in January, we took the time to put together a charter and set of working practices.

  • `master` should always be releasable
  • We would use Pull Requests (PRs) to get code changes into master
  • Code would be reviewed by a peer before merging
  • Branches would be short-lived (preferably hours, maximum 2 days)
  • PRs should be a small
  • PRs should be speedily merged (again, preferably hours, maximum 2 days)
  • We prefer pairing over solo work (almost everything should be paired on)
  • Use common sense
Thanks, Slack Bot

Ask the experts

Back in February, ThoughtWorks came in to help us scope out a new project, whilst they were here, we took the opportunity to quiz them on Trunk Based Development. I had a reasonable understanding of what TBD was (just push straight to master :trollface:), and it felt like (other than using PRs) that was how Wolves were operating. I went along to see if there was something I was missing.

Quizzing ThoughtWorks on Trunk Based Development

The end?

The SQL Census team were a pretty small: for most of the time we were only 3 engineers + a tech lead. A lot of the time we operated as 2 pairs, making sure everyone got a chance to pair with everyone else.

Our Early Access Program journey whiteboard

To PR or Not to PR

Could we reduce context switching and at the same time reduce total consecutive PRs whilst also reducing how long they were open? We were already pairing by default on every task… there were 2 pairs of eyes on almost everything, and who gives a damn about seeing UI tweaks. Why would you submit a PR if you hadn’t tested it? Even if it wasn’t right, it’s easy to roll back or forward.

Nice work Parker…
  • If you want a review, create a PR and request one
  • If it’s a single commit, merge it straight to master and push
  • If you’ve got a group of related commits:
  • — Create a branch with a “What? Why? Tested?” PR
  • — Merge when green (yep, merge your own PR)
  • We’d introduce a fortnightly 1hr lean coffee team code review session to look at how we could improve/standardise
  • Use common sense

Don’t be Desmond aka Trust Your Team

So it turns out that we were essentially already doing Trunk Based Development — and you probably are too! Kudos! The only thing slowing us down was the idea that a Code Review had to mean a PR. Once we got past that idea, days felt more productive and less fragmented.

Ingeniously Simple

How Redgate build ingeniously simple products, from inception to delivery.

Alasdair Parker

Written by

Ingeniously Simple

How Redgate build ingeniously simple products, from inception to delivery.