Recently there was a debate about using client-specific release branches in an attempt to protect them from change. A little background, the software is used by multiple clients. Each client might have a different release deployed to production and new releases of the software are developed every 2 weeks.

There was an idea about using client-specific releases with the intent of isolating them from change to somehow protect those clients from bugs. Let’s take a look at the two approaches.

All clients use the same release branches – Unidirectional updates

Not having client-specific branches is very nice. Any changes you make in one release branch is merged into all subsequent branches.

So let’s say you make a change in 1.0, it gets merged all the way up to 1.3. If one client is using 1.1 and another 1.3, it doesn’t cause any problems. They will all eventually get all bug fixes/updates.

As long as the direction of updates always flows in one direction you’ll be very happy. You will have very few merge conflicts if all changes are merged in a timely manner.

Client-specific branches – Bidirectional updates

Now let’s look at the mess that’s created with client-specific branches. Let’s say clients FAS and MST use their own branches.

There are three majors problems with this approach because we are introducing bidirectional update flows:

1. Now the process of making changes to 1.0 involves merging into 1.0.FAS and later, into 1.2.MST. The other scenario is when FAS requests changes, you need to merge 1.0.FAS into 1.0 and then do your regular merging. This causes a lot of extra work and results in more merge conflicts.

2. As soon as FAS switches to using 1.0.FAS, they will stop receiving all bugfixes/improvements that are applied to 1.0. In the effort to isolate FAS from change, it now exists outside of the standard flow of updates.

3. Now we are making it very difficult for developers to do refactorings/re-structuring of code because it will be extremely difficult to merge. Suppose a developer has worked on significant re-structuring for 1.2. It was merged into 1.3. However, after a few days of being happy, MST now wants changes. Unfortunately, it’s well behind 1.2 and has stopped receiving all updates. You can make the changes directly to 1.2.MST, but in order to merge those into 1.2 and all subsequent branches will be very difficult if not impossible.

Code improvements matter

Another troubling concept came out of these discussions related to #3 above. It seems some people have the notion that code improvements, whether it’s performance improvements or code structure improvements, don’t matter. Clients don’t see code improvements and usually don’t notice performance improvements, therefore they don’t matter.

This idea is absurd and very dangerous. First of all, the goal of performance improvements is for the client not to notice them. As the number of concurrent users/traffic increases, clients should see no change in performance. The only way to accomplish that is to prioritize regularly looking for bottlenecks and other areas of improvement. Clients will most certainly notice performance degradation.

While it’s true that clients usually don’t see the actual code improvements directly, they experience the many benefits of them. If code improvements are regularly prioritized, they experience less future bugs, greater developer productivity, a software product that is easier to change, and more confidence in implementing new significant features.

So please never make the mistake of thinking client satisfaction and regular prioritized code improvements don’t go hand in hand.