So, how much do you enjoy merging code from different development branches? Not at all? Neither do I. If you’re like me, you’ve probably had your fair share of merge nightmares. Remember the project I talked about in Chapter 12, Discover Organizational Metrics in Your Codebase? You know, the story of the project that got stacked with four times as many developers as needed to get it done “faster”?
In that project, one of the major bottlenecks turned out to be parallel work. We often spent a few hours adding a feature, only to find out that the relevant code had been rewritten in another branch. Not only is that way of working frustrating, it’s also expensive and a sure way to breed defects. We don’t want that.
Better tools like Git and Mercurial have improved the situation, but we cannot expect our tools to cure dysfunctional practices. Let’s see how code churn can uncover them.
Code churn refers to a family of measures that reflect how rapidly your codebase evolves. Each time you commit a change to your source code, your version-control system records the lines you’ve added, modified, and deleted. The following image shows how it looks in Git.

Over time, we get thousands of such small churn contributions in our repositories. Each one of them provides a small hint about how we work. Let’s see how we can use that to discover process loss in our organization.