Home > Messages from the Ether > Branch causes

Branch causes

At this hypothetical company, we have a shared code base linked across several branches in source control to accommodate customizations for each client. Customizations include not only configuration file changes but also source code changes that cause the code to be branched from the "base" code. The base code is simply that subset (perhaps 80%) which is linked across all client branches and has no breaks. It's interesting for the fact that it exists only in concept.

This branching is an obvious source of distress. Linked code causes long-distance (cross-client) bugs; branched code isolates features and fixes. What to do?

We have had discussions of better arrangements:

• Institute a policy of production branches for each client, where code moves from the current system to an isolated branch before it gets to the client,


• Get source control software that provides greater control over branching,


• Refactor to more accurately isolate client-specific code

I had a discussion recently that was borderline enlightening concerning the first issue described above (long-distance bugs). More than one client has become angry(er) at us because a fix in another client's code propagated into a bug in their code. Although I haven't researched this heavily against the actual events, the only way that this could happen with shared code is that client-specific configuration settings or data:

1. Caused a different path in the shared code to be executed than that which was tested,


2. Caused the same path to be executed, when it should have been different

In Steve Maguire's book Writing Solid Code, he has a chapter titled "Step Through Your Code." Some relevant quotes:

• The best way to write bug-free code is to actively step through all new or modified code to watch it execute, and to verify that every instruction does exactly what you intended it to do.
• In addition to stepping through your error conditions, you should also step through every possible path in your code.
• What About Sweeping Changes? Programmers who step through their code soon learn to write small, easily testable functions because stepping through large functions is so painful.

So, to fix our source control problems, we don't have to get mired down in more configuration management paperwork. We just need to start being better programmers. When I had first read Writing Solid Code years ago, I began slowly adopting its suggestions. I have since gotten sloppy, but always remember that I consciously never regretted the little extra time it took to force the debugger to step through each branch. The effort was always rewarded either by a discovery of a subtle problem or by the added confidence in that piece of code. It become one block that was less of an unknown when trouble happened.