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.
"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?"
For 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.
On 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.