Branching to Distraction

Example: The Release Line

Consider the situation where a customer reports an issue in the code between the time it was initially released and when the next release is scheduled to ship. Working on a release line branch can be an appealing solution, because branches provide isolation and a perception of simplicity and safety, since you are starting out with code you believe to be tested and release quality.

The belief that you are starting out with more stable code does not remove all of the perceived added cost over delivering the code on the main line for the following reasons:

• Working on a branch creates extra work.
• Working on a released code line usually does not save as much effort as you might have thought.

Regardless of the nature of the fix, you are splitting your attention from the current project work. You may be fixing a problem that has already been addressed on the active development line, and you are constrained to using versions of frameworks and tools that the released code was delivered with, even though using the newer versions would make work easier. Developers have to deal with the frustration and cognitive costs of working with a code base that is different than what they work with daily.

In many cases, you may want to migrate the work you did on the branch to the main development line by merging the code changes. The complexity of a merge can range from simple to impossible. Simple changes involving small text changes when the main line has changed little can be done quickly and easily. In other cases, merging a complex change to a heavily changed main line may not be possible without significant manual intervention (though there is some research about tools that support refactoring).