In the spirit of one of our core values, #AlwaysBeLearning, we’ve teamed up with continuous delivery thought leader, Dave Farley, on a series of Tech Blogs.

Last week we looked at how to balance pair programming with individual working styles and the need for head-down focused time. This week, we get Dave’s top tips for adopting trunk based development.

“Currently at MarketInvoice we use short-lived feature branches that are merged to master post-code review. How would you recommend we shift towards trunk based development and are there any other practices you would recommend to reduce/eliminate the bottleneck of code review?”

I perceive three barriers to the adoption of trunk based development in the teams that I work with…

1. The need for code review
2. A cultural assumption that you only commit (to master/trunk) when work is complete
3. A lack of confidence in automated tests

Code reviews

I think that code review is a very useful practice. We get good feedback on the quality of our work, we may get some new ideas that we hadn’t thought of, we are forced to justify our thinking to someone else, and, if we work in a regulated industry, we get to say that our code was checked by someone else.

All of these are good things, but we can get them all, and more, if we adopt pair programming.

Code review is great, but it happens when we think that we have finished. That is a bit too late to find out that we could have done better. From a feedback perspective, it would be much more effective if we could find out that an idea, or approach, could be improved before, or immediately after, we have written the code rather than after we thought we had finished. Pair programming means that we get that feedback close to the point when it is most valuable.

Pair programming is a code review, and so satisfies the regulatory need for our changes to be checked by someone else, at least is has in every regulatory regime that I have seen. Pair programming is also much more than just a continual review. One way to look at it is that we get the code review as a side benefit, for free.

This means that the review does not impose any delay on the development. The code is being reviewed as it is written and so the review is both more thorough and adds no additional time to the development process.

So, my first answer is… pair programming!

Don’t wait to commit

This is a mindset thing, and makes perfect sense. It seems very logical to assume that the ideal time to commit our changes is when we think that they are ready for use – the feature that we are working on is complete.

I think it is a bit more complicated than that though. I describe this in more detail in my post on “Continuous Integration and Feature Branching”

If we want the benefits of continuous integration we need to commit more frequently than when we think that we are finished. The only definitive point at which we can evaluate our changes is when we evaluate them with the “production version” of our code which is represented by trunk (or master). CI on a branch is not CI! It is neither integration, at least not with the version of the code that will be deployed into production, nor is it continuous because you only integrate, with the version of the code that is deployed into production, when the feature is “finished”.

So to practice continuous integration, which is a prerequisite for Continuous Delivery, we have to commit more frequently to the copy of code destined for production and so we must change our working practices.

This is a big shift for some people. It is probably one of the most profound shifts of mindset for a developer in the adoption of continuous delivery. “What, you want me to commit changes before I am finished?” – Yes!

Continuous delivery is defined by working in a way so that your software is in a releasable state after every commit. That doesn’t mean that all of the code needs to be useful. It just means that it “works” and doesn’t break anything else.

In the language of continuous delivery we aim to “separate deployment from release”. We can deploy small, simple, safe changes into production and only “release” a feature when all of those small changes add up to something useful.

This leads us into the territory of a much more evolutionary approach to design. Instead of thinking about everything up front, even for a small feature, we will work in a fine-grained, iterative way that allows us to try ideas and discard them if necessary on the route towards something that works better.

This has lots of good side-effects. Not least it means that I will design my code to allow me to change my mind and get things wrong without wasting all of my work. That means that my code will have good separation of concerns, be modular and will use abstractions to hide the details of one part of my design from others. All of these are hallmarks of high-quality code. So by working more incrementally, I get higher quality designs.

Automated testing

“I can’t commit to trunk before I am finished because I may break something”. To me, that speaks of a lack of confidence in testing and/or a very traditional mindset when it comes to testing strategy.

It kind of assumes that you can’t test your feature until it is finished. I think that that is old-school thinking. This is a problem that we know how to solve – “Test first!”.

This problem in part stems from the language that we have chosen to describe the use of automation to verify that our code works. We call these things “tests” which tends to make us think of performing this verification as a final step before we release. I wonder if the adoption of a “test-first” approach would have been different if we had called these things “specifications” rather than tests. “Specify first” seems more obvious perhaps than “test first”.

If we see our automated evaluations as “specifications” that define the behaviour that we want of our systems, we must obviously do the thinking, and create the automated version of these specifications, before we start to meet them by building code.

By building software to meet executable specifications of its behaviour we eliminate whole classes of errors, but even more importantly, we drive the design of our systems towards higher-quality. I argue this in an earlier post on “Test Driven Development“. The properties of code that make it testable are the same properties that we value in “high quality code”.

I have worked on large-scale complex systems where we could release at any time without fear of breaking things because our automated testing caught the vast majority of defects. Employing tests as “executable specifications” which describe the desired behaviours of our systems has a dramatic impact on the quality of the code that we produce.

In a study of production defects the authors estimated that over 70% of production defects would be eliminated by a more disciplined use of automated testing.

Using a test-first approach drives quality into our designs, protects against the most common causes of production defects and allow us to move forward with more confidence.

Dave Farley is co-author of the Jolt-award winning book ‘Continuous Delivery’ as well as a thought leader in devops and software development. He is the founder and MD of Continuous Delivery Ltd where he works as an independent Software Consultant.