FLOWCON 2025

Title: Non-Blocking Continuous Code Reviews, a Case Study

The problem with the current most commonly accepted way of running code reviews using Pull Requests is that they have the nasty habit of blocking the flow of delivery. They introduce a cost of delay. Delays reduce feedback and drive down quality.

The usual way to achieve fast efficient and effective Continuous Code Reviews without disrupting the flow of delivery is through Pair Programming or Team Programming. However, for various valid reasons, these are often a cultural stretch for many teams and organisations.

In 2012, a novice team practising trunk-based development set up a fairly uncommon but efficient alternative to implementing continuous code reviews on mainline without ever blocking the flow of delivery. This team went from a bunch of rag-tags to becoming a reference team in the organisation, with auditors falling on the floor because of the amount of quality the team delivered.

Sum up the session in only 1 sentence
How to run code reviews with trunk-based development when pair programming is a cultural stretch?

What are the 3 top takeaways from your session or workshop?
Be able to explain how Pull Requests disable the benefits of Continuous Delivery. Be able to enumerate the key ideas behind non-blocking code reviews. Understand how non-blocking code reviews are an enabler for Continuous Delivery.

Cf. Didier Girard

Sum up the session in only 1 sentence
cf. Didier Girard

What are the 3 top takeaways from your session or workshop?
cf. Didier Girard

So You’ve Built It, Now Support It. From Chaos to Happy Customers - Doing the Gardening At Bloom & Wild

Humans make mistakes, it’s a fact of life. Despite our best intentions, and no matter how many checks we put in place, sometimes things go wrong. It’s no different with software. To move at speed then it’s inevitable that production issues will happen. Sometimes it’s your code that doesn’t work as expected, sometimes dependencies break, sometimes infrastructure breaks. Sometimes that once in a lifetime event happens. Again.

This talk is a story about support. It’s a real life story of how what was a chaotic situation, with unhappy customers and developers, has been turned around to something that keeps our customers happy, and is even fun to be a part of.

Sum up the session in only 1 sentence
All teams should support their systems in production and I'm going to explain what I've learnt about doing that, with added flowers :)

What are the 3 top takeaways from your session or workshop?
1. Why they’ll always be some need for production support, why needing it isn’t a indication of failure and how we can make it a nicer experience
2. The different ways that we've supported our systems at Bloom & Wild and what we've learnt as we've rapidly scaled the team
3. A little about flowers and a lot about learning

No Code, Low Code, Machine Code

What level of abstraction is just right?

Everything looks solvable if you ignore most of the complications. Many things look impossible if you’re stuck in the weeds. The current fashion for low/no code solutions heralds the cyclical return to looking for solutions that require softer skillsets. When is this appropriate and when is it a recipe for disaster?

Sum up the session in only 1 sentence
There is no silver bullet (reprise)

What are the 3 top takeaways from your session or workshop?
- Essential complexity cannot not be simplified away - No code/low code solutions are only beneficial in limited domains - AI and ML are tools not solutions