Feature Branching Is Not Evil
Version management is one of the more misunderstood aspects of agile software development. Branching is particularly maligned—some people believe branching and pull requests are inherently bad. True, branching done poorly can slow down a team, but advocating for avoiding branching altogether can lead you to ignore the more important goal of an agile process: rapid integration of changes to minimize unknown risks.
Arguments about whether branches are good or bad are often about the wrong thing. The question shouldn’t be “How do we use branches?” but rather “Do changes get integrated and tested rapidly enough?”
The main challenge to agile development is integrating too slowly. Frequent integration helps the team verify the state of the system and maintain working software, but the ideal frequency varies from team to team.
For some teams, merging once a day is a good cadence. For others, it’s more frequently. Even with a single code line, you can still have slow integration when team members keep code in their workspaces. The metric that matters isn’t the number of code lines but the time it takes to merge to master.
Small changes integrated quickly are good. This allows for validation though automated testing and correction of any errors. But passing tests only provide useful feedback if they’re testing the right things. A second set of eyes on the code before merging can also help to find errors—especially the ones you didn’t think to test for.
On some teams, pair programming provides for this kind of review. Others may choose to do task branches, pull requests, and code reviews. Either is fine, as long as the team can meet its agreement about how often to integrate code—and, consequently, meet its ultimate goal of delivering working code to production.
Even with pair programming and good automation, additional review steps can be helpful. I once worked with a team that had excellent discipline around test-driven development and test automation, but with some gaps. After changes, the team ignored a suggestion that we run the application before merging and deploying it, because “it passed all the tests, so it works!” We deployed the application, only to have the business owner run in to report that part of the user interface was missing—a typo led to a page not rendering. The team was so confident in its automation that it had become complacent.
While single-code-line development can force a testing ethic, it may also result in slow integration because developers might delay pushing changes from their workspace due to lack of confidence in their testing. Delivering from a single code line is the best to keep your code agile. But there are many ways to get there. As with any practice, you need to evaluate it periodically in the context of the proper metrics. For agile teams, the most relevant code-line metric is how long it takes code to get into production.
Before outright forbidding any practice, consider the goal you wish to achieve and the metrics that will help you understand your success.
