… something on Trunk Based Development

Jun 18 · 7 min read

Change of Circumstance

In the last month the team’s focus has changed and rather than working in a large established codebase (alongside two other teams) with a mature (and mandatory) PR process, we have switched to spiking and developing from scratch.

Making small changes

As I said, we’re building from scratch and doing a fair amount of spikes, so the code had been put together to get something working, but not really ‘designed’.

An evolving design

At one point it became obvious that the interface could be improved by a change I’d missed. So we tweaked that and pushed that too. No drama.

Minimise Batch Sizes

Working in the small reduces the risk of each change. As one of my favourite quotes says:

Time and Energy

Not seeking perfection

There is also a sense that each change does not have to seek perfection, but be a coherent self-contained change. I have seen the fear of changes not being perfect paralyse a team from making virtually any changes at all. No one wants to make a change in case it is criticised or found to be the cause of an issue later. The team lacked Psychological Safety which I’ll return to in the next section.

Safe to Fail

Psychological Safety is where team members being able to fail in front of each other with no recriminations, so they don’t feel they have to try to hide it; it goes hand in hand with a No Blame culture.


Last week my colleague Alasdair Parker published a blog on how moving to Trunk Based Development (TBD) had upped the level of trust in his team. I think this is a great advertisement for moving to TBD.

Continuous Integration

Whilst Continuous Integration servers have undoubtedly improved over time, allowing builds based on all branches as if they were master/trunk, the term Continuous Integration refers to Integration happening in both directions, continously; not just occasionally, or even frequently. If work isn’t integrated on to trunk or master every day it’s not Continuous Integration, it’s just a Build Machine.

Continuous Delivery

Continuous Delivery demands even more. Having mentioned the Accelerate book and it’s metrics already, high performing teams push a commit and have that change in Live/Production in timeframes measured in minutes; you just can’t do that with a PR process is place.

Shared Ownership

In Open Source projects there is often (rightly or wrongly) one or more people with elevated status — who give the yay or nay on what changes are accepted; the owners of the codebase. This is an enforced type of heirarchy.

Ingeniously Simple

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


Written by

@TheCodeCleaner agile consultant, committed clean coder, slayer of complexity and harbinger of tea. Remourner. Now 'part of the team' at @RedGateProdDev

Ingeniously Simple

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