I think it's probably true that most teams believe that if they commit straight to main, everything will break. Nothing will be deployable and chaos will rain. This is completely the opposite of what we see in teams that practice true continuous integration. In today's episode, I'm going to show you a real team who did exactly this. Committed straight to main, no branches, non-blocking code reviews in a new domain under tight deadlines and absolutely thrived. And we have the data

to back up those claims.

Hi, welcome to the modern software engineering channel. I'm Dave Farley and if you haven't been here before, please do hit subscribe and if you enjoy the content today, hit like and if you really enjoy it, join us in the conversation in the in the comments below as well. This channel is about software engineering done well based on evidence, experimentation, and the principles that help us to build better systems. Today I'm sharing a case study from a team who ex adopted trunkbased

development in its purest form. Commit straight to main, push to origin, deploy frequently, get feedback, repeat. They also tried non-blocking code reviews. Some of these things worked beautifully, some didn't, but it's all incredibly instructive. This company is called MFT Energy, and their business is Energy Trading. One of the engineers involved in this change, Martin Mortensson, told me their story and sent me the data that the team collected and their survey

results from their reflections and their follow-up analysis. And it's a gold mine for understanding how real teams succeed with fast flow practices. So I want to thank both MFTt and Martin for allowing me to share their story with you. Let's begin with the environment. This was a new team working in a new domain power trading building a bidding or auction integration service. They were working to critical deadlines and sitting close to their users meaning that they were

getting great feedback. They had one test environment and one production environment. The team had mixed levels of experience but very little experience of test-driven development or unit testing. During the course of this project, they made roughly 2,500 commits. 90% of those were fewer than 200 lines of code. So, this is not some perfectly groomed engineering utopia. This is a realistic team building tricky software under pressure in a context where fast iteration really matters. Let

me pause there and say thank you to our sponsors. We're extremely fortunate to be sponsored by Eco Experts, Transfig and Mail Trap. Transfig is a financial technology company applying advanced continuous delivery techniques to deliver low latency trade routting services to some of the biggest financial institutions in the world. All of these companies though offer products and services that are extremely well aligned with the topics that we discuss on this channel every week. So, if

you're looking for excellence in continuous delivery and software engineering, click on the links in the description below and check them out. The team used what Martin calls main asdefault trunkbased development or MAD TBD if you're if you're an acronym person. Essentially commits straight to Maine and the pipeline builds the system, runs the unit test, deploys to test environment, and runs any acceptance tests. And if all these tests pass, the developer can then deploy into

production. I'd call this continuous delivery. And interestingly, in this case though, there's no mandatory pair programming, no strict test-driven development requirements, no pull request gates, no rigid review process. Instead, the developers chose what they thought was necessary for each feature. However, they do make changes in very small increments, use feature toggles to isolate work in progress, and they validate their changes by observing them in test in production or via fast

feedback from users. All of this is described in more detail in Martin's LinkedIn article, and there's a link to that in the description below. If you'd like to learn more about how to apply Trumpbased development to your work, check out my new how-to guide on this topic, and there's a link to that in the description, too. Before they began, the team had all the usual concerns. Main will break all the time. It won't be deployable. Feature toggles will be painful. Quality will suffer without

pull requests. Developers won't be responsible enough. So, at the end of the project, they surveyed the team and and figured out what they thought. The survey used the questioning approach that I first came across from the Accelerate book, asking a variety of questions in different ways and getting people to score them. But how you ask the questions is important and I think they did a pretty good job of that from my reading at least. One of the first questions is Maine is often broken and

we can't build and the team were asked to score that from strongly disagree to strongly agree. Every single person in this case that was questioned strongly disagreed with this statement. Maine is continually in a deployable state. The average score of this question was 8.2 out of 10, but actually one person misinterpreted the question apparently. So the real average was 9 out of 10 if you discard the misinterpreted response. Quality of the service. Our service has

an overall good quality scored 8.5 out of 10. And subjectively their scores on the Dora metrics were also extremely good. Change lead time was low, deployment frequency was high. Change failure rate was low and with very small blast radius when there was a problem. And the meanantime to recover was also low. This success wasn't magic. It was engineering. Three principles underpin what what it was that they did and they align extremely well with the science behind continuous delivery and modern

software engineering. First, small batches reduce risk. They made very small commits, often dozens per day across the team. Smaller batches mean that there are fewer unknown unknowns and that each change is individually easier to reason about and easier to fix if something goes wrong. This is exactly what we see in every Dora report since 2014. Second, fast feedback hardens the system. Small changes deployed frequently get validated in the real world. The team used feature toggles,

dark launches, incremental database changes, mock data, and parallel verification to help them get very fast feedback, whatever the nature of their change. These real world testing strategies are detailed in the examples near the end of Martin's article. Third, low traction costs encourage good behavior and keep the flow fast. Blocking pull requests, long live branches, and heavy Q&A regimes slow teams down. Slower teams make change in larger batches. Larger batches break

more things. This is Cozy's transaction cost principle in action. By keeping the cost of change low, they kept changes small safe observable and recoverable. This fast flow, low transaction, low ceremony process approach to things encourages a more collaborative working style, too. Here are the things that the team said. Rapid feedback fosters a culture where people talk and evolve each other daily. Features are released faster. Bugs are discovered early and fixed early. The

feedback loop with the trading team strengthened dramatically. The pace and agility surprised us while keeping production safe. This is what the lived experience of working with this kind of flow looks like. Close to users, lots of feedback, high trust, fast iteration, low fear. This is exactly the environment that produces high performance teams. All of this is great, but not everything went so well. While trunkbased development was a big success for this team, the non-blocking review

approach did not succeed. The average score for non-blocking review was 6 out of 10 with a negative net promoter score of minus7. Apparently, there were several problems. The main one was that people didn't prioritize reviews enough. Non-blocking was interpreted to mean non-urgent. So, reviews were not conducted close to the time when the work was done. So, feedback became stale. Many people didn't see the value and effectively voted with their feet. The team reported that the tool that

they chose to manage their review process lacked some key features and Martin lists some of those desirable missing features in his article. But to be honest, I see this more as a problem of them missing the point of the non-blocking reviews rather than a problem of tooling. Non-blocking review is meant to be a less formal approach. I prefer pair or mob programming myself to non-blocking review, but a non-blocking review approach makes a lot of sense to me. I talk about non-locking reviews in

this video, but I think that my skepticism of this being a tooling problem is borne out a little by their fourth complaint about the non-blocking approach. The team saw no shared purpose for the code reviews. This is important. People didn't know what the code reviews were meant to be for. Were they for security bugs compliance knowledge sharing, or deployment safety? If you don't agree on why you're reviewing the code, you're not going to get any consistent value from the reviews that

come out of that, whatever form they take. This team wasn't using enough realtime sparring. The team needed more pairing, more design discussions, and more in-person collaboration. I think overall trunkbased development worked extremely well but non-blocking review worked but only moderately and only then when the team took a more disciplined approach to it. The team though overwhelmingly preferred the trunkbased development approach scoring it 7.6 out of 10 overall with a net promoter score

of 33. Perhaps though, most tellingly of all, when they were asked would they continue using trunkbased development on future projects, this got a score of 8.5 out of 10. Interestingly, despite mine and many other people's assumptions on the use of trunkbased development, this team found that it worked better than their more usual experience of feature branches, even without the need for mandatory test-driven development, hair programming, or some heavy review process. Even with their informal

approach to trunkbased development, quality went up, speed went up, and safety went up. In his article, Martin says that optimizing for continuously delivering the smallest robust increments of change creates quality and stability all by itself. And I couldn't agree more. This is precisely what the evidence from continuous delivery tells us, too. Small batch sizes plus fast feedback equals better outcomes. Crucial to this kind of feedback is an effective deployment pipeline. If you'd like to

learn more about how to build great deployment pipelines, I have a special offer on my anatomy of a deployment pipeline training course. Check the link in the description below for a 20% discount on that course. So, I think that the lessons from all of this are trunkbased development isn't dangerous. Big batches are. Small increments validated frequently is the best way to create robust systems. A constantly deployable main is an outcome of good engineering, not heavy process. Code

review is only valuable if you agree what it's for. Non-blocking reviews need a clear understanding of their purpose and a real-time collaboration to complement them. Most teams can try trunkbased development sooner than they think. You don't need perfect unit test coverage to begin. I think that test-driven development and pair programming are great tools and that you will get better results when you add these things to trunkbased development, but they aren't prerequisites for it.

The easiest place to begin trunkbased development and to add all of these things is at the start of a green field project. But you don't need months of preparation to add trunkbased development to an existing project. What you need is that you need to organize your work in small batches. You need to apply feature toggles, adopt a safe incremental design, and gather fast feedback, use observability and user alignment with what it is that you're doing. Everything else is optional. This

is a fantastic case study because it's real. Real engineers, real deadlines, real domain complexity, real constraints. And they succeeded not by adding ceremony, but by removing friction. Trunkbased development isn't about recklessness. It's about designing your work so that each change is small, safe, observable, and reversible. Thank you very much for watching. And if you enjoy our stuff here on the Modern Software Engineering channel, please do consider supporting us by joining our

Patreon community. And to all existing Patreon members, I'd like to once again thank you for your ongoing support and look forward to seeing you soon in our upcoming webinar. Thanks and bye-bye.