This article is the second in a series on small batches.

When I set out to write about the benefits of small batches in software development, I thought maybe I’d come up with a solid list of “5 Reasons Small Batches are Awesome.” But as I talked to people about the topic, the list kept growing… soon I had 10. Then 12. Then 14.

Then the paradox of a big article about small batches was pointed out, so I determined to split this into a three-parter. If you’re new here, consider subscribing to be notified when the next installment lands!

Last week I provided a brief introduction to the concept of batch size, and talked about some of the business benefits of small batches.

Today I want to talk about the impact that smaller batches releases and pull requests can have on the actual code we produce.

Fewer conflicts

One of the more obvious benefits of small batch sizes is that we have less chance of merge conflicts. It’s exactly this thought that leads to the concept of Continuous Integration. Whenever multiple people are working on the same code base, the longer the work is kept in isolation (larger batches), the more likely there is to be a conflict, and the more likely a conflict is to be difficult to resolve.

Keeping your batches small, and short-lived, minimizes this risk.

More effective code review

We’ve all been there. You write a quick 10-line change, and get 16 code review comments.

Then later you push up a 1,600-line beast, and get an immediate “LGTM!”

Now I’m not promoting bikeshedding in code review, but it’s pretty obvious that big batches of code get less review attention. Keeping your PRs small is one of the best ways to get more out of your code review.

Promotes modular design

Coding practices such as Test-Driven Development (TDD), TCR, and The Mikado Method are centered around the concept of small, minutes- or seconds-long batches. This way of working naturally produces modular software, which is easy to extend, replace, and test.

At the feature/story level, learning the skill of story slicing also provides the same benefit, by creating features that are less entangled with each other.

Better prioritization

The Pareto principle (aka the 80/20 rule) tells us that for many things, 80% of the consequences come from 20% of the causes. Translated to software development, this would be “80% of the value comes from 20% of the features”. We may not always know which 20% of the features to create to get that 80% value. But if we can split our changes into smaller bits, and release them as they are completed, we’ll eventually know when we’ve hit that 80% value mark (or something like it). Maybe then we’ll decide the remaining unwritten features aren’t worth doing, and move on to more valuable tasks.

Faster and safer break/fix

We all know the pain of releasing software we think is ready, only to discover a serious problem as soon as real humans are using it.

In the CD-ROM days, we’d send a patch or hotfix on floppy disk, or maybe over the blazing fast 28.8k Internet of the day. This bad habit of hotfixing has followed many teams well into the 21st century. But it’s a dangerous habit that smaller batches obviates.

If your release cycle is shortened from weeks to minutes, then every release can be a hotfix. This means faster response to both serious and trivial bugs, and a much safer release process (since the hotfix process doesn’t have to circumvent normal quality checks).

What’s next?

In the final installment, I write about what I find to be the most exciting aspect of small batches: The psychological benefits they bring us as individuals and a team.