Variant Management Starts with Design
A recent discussion on LinkedIn’s configuration and release management forum got me all riled up. The forum post described a work situation where there were 100-plus different customer variants of a particular product. In this case, it was necessary to tag different versions of each file to the right variant because there wasn’t adequate branching capability in the current version control tool in use.
Someone on the forum asked how can you get management to support higher-end CM tools to help deal with this problem. Indeed, this person was using a first generation source code control tool.
By all means, go ahead and upgrade your tools. However, keep in mind that this will not solve the problem at hand.
The CM group of an organization is often handed this problem, in which all the customer variants need to be handled in a reliable and sane manner. If you’re ever handed this problem as a CM manager, take it, but make sure you have the authority to dictate that some product design changes will be needed.
The key to software variant handling is to move the variant customization process beyond the coding phase and out to the customer’s premises, whenever possible. At that point, it becomes simpler to manage the variants.
I’m not suggesting you send the source code and a compiler to your customer. You know which features make up your dozens of variants. You should code those variants such that each feature can be enabled or disabled at the customer site.
Does this require some great architectural advance to your product? No. Start with an up-front requirement for design that says each feature must be easily enabled or disabled at run-time through a single variable. Then add to that a run-time interface that allows you to set each feature variable. Any programmer will tell you that the addition of a feature switch is a trivial matter.
Too often, programmers will clone a new version of a file, modifying it for the specific variant required. Not only have they added redundant code, but now, when a problem is found, it has to be fixed in two places until the code is refactored. At the Programmers’ Stack Exchange, the problems with such branching are debated.
You should use a condition on your feature variable to segregate feature-dependent code clauses. Now you have one set of code with two behaviors. Do this half-a-dozen times and you have up to sixty-four run-time variants.
Now you don’t have to overload your branching with variants and your customers will be grateful, as you permit them to dynamically modify the behavior of the software product.
Variant management is a CM issue, but it has to be dealt with in the product design first.
