Merge More Frequently

One of the biggest lessons from Lean manufacturing principles (Toyota Production System, etc), is the importance of working in small batches. Limiting "work-in-process" inventory is an essential technique for keeping costs under control and reducing the risk of missing deadlines. When consumer software was primarily shipped on CD-ROM, there was a limit to how small these batches could be (updates often happened at most once per year).  In the era of web application development, however, teams can deliver updates on a daily basis and fully reap the benefits of working on small chunks at a time.

In Extreme Programming, one of the coding practices is Integrate Often.

"Developers should be integrating and commiting code into the code repository every few hours, when ever possible. In any case never hold onto changes for more than a day."

This practice comes out of the Agile renaissance, when the year-long Waterfall development cycles were replaced with shorter iterative approaches. In the recent wave of startups, terms like Minimum Viable Product and Pivot have become common. These tactics are enabled by development teams working on small batches of features in short iterations. The longer development cycles of the past are incompatible with the fast-moving startups of today.

The hallmark of an agile company is one that can rapidly respond to changing market conditions. This requires the CEO to be able to redirect the product development team at a moment's notice. An important question any developer should ask about their current project is: "If I had to ship this immediately, how many days would I need to get it into shape?"

Graph1.pngFor a given feature, let us define the term Ship Number to mean the number of days it would take to merge the code into master such that it would be in a stable state. On teams that do not merge their features for longer periods of time, the Ship Number of a branch tends to look like this over its lifetime. At the moment a feature branch is created, the Ship Number is always 0. As behavior is added or modified, the Ship Number rises because the feature is only partially implemented and would not be stable if merged. Once the feature is closer to completion, its Ship Number begins to drop until finally it is ready for merge. The Time axis here could be anywhere from a few weeks to several months.

Graph2.pngOn teams that merge frequently, we get a graph that looks more like this. In this case, the Ship Number never gets too high because we are integrating frequently. By keeping their Ship Number low this team makes it easier for their company to decide to drop some requirements and ship immediately in order to capitalize on a market opportunity.

Practically speaking, the takeaway for a developer or team lead is that you should always be looking for ways to break up a feature or story into small pieces which can each be finished in a day or two. Since code is not really done until it has been merged into the master branch, your goal should be to merge any branch you are working on back into master every day or two.

If you are not used to working in this way, this may seem like a herculean feat. I will be writing more about strategies for breaking up features into small pieces in later posts. For now, it is enough just to embrace the goal of trying to merge your branches as frequently as possible. So I don't leave you completely on your own, I recommend looking into Feature Toggles.


Showing 1 reaction

Please check your e-mail for a link to activate your account.
  • Pierre-Francoys Brousseau
    commented 2014-05-03 17:35:12 -0700
    While the “shipping often” may not apply to mobile apps especially if updates are not automatic, or require user action/reaction in any way (getting out of that is a whole other story, and sometimes you can’t). However, merge more often still applies! I’d say “ship often” is more of a side result of merge more often here; and that makes sense for web applications that don’t require extensive code deployment (as opposed to installed apps).

    As for the rest, I completely agree. Add to that:
    1) Merging often makes automatic merging a whole lot more likely to succeed (no merge conflicts).
    2) Code review is simpler. If the merge affects fewer functions, you are more likely to identify possible issues.
    3) Catch design flaws earlier: assuming you do code reviews on merges / pull requests, you may save days of development by identifying merge issues or design flaws quickly
    4) Breaking up tasks in ways that keep your “Ship Number” low, you may find that co-workers have an easier time helping out on parts of the tasks.

    Nice post!