The simplest method of implementing a product configuration management (PCM) mechanism is also one the most secure. The code-time PCM pattern involves a software engineer duplicating and modifying the source code tree for each product configuration to be supported. With modern revision control tools, it is a fairly simple task to duplicate the code base, and such tools normally provide sophisticated capabilities to help propagate changes across multiple code branches. The end result of this process is that each product configuration is custom tailored to its specific needs, and generally only includes the source code necessary for that configuration. Once released, the software product is immutable and cannot be altered by an end-user in an attempt to activate latent functionality, since such functionality will not be present if it were not part of the configuration.
The primary drawback with the code-time PCM pattern is in the area of agility. While the process for accomplishing this pattern is relatively simple, it is nonetheless time-consuming, and often involves a large amount of repetitive work. Even if the source code changes are rather trivial, the process still often involves a substantial amount of downstream work and time in the areas of builds, installers, testing and release.
To help understand the amount of work involved in using the code-time PCM pattern, I will present an example here based on a fictitious financial software product named Make-Me-Money. The code-base for this product consists of approximately 10,000 source files, and it takes about four hours to perform a full build of the product. Product Management has decided that there will be three distinct configurations of the product to provide good/better/best choices for the customers. The good configuration will provide basic financial management functionality. The better configuration will add a set of financial videos and tutorials, while the best configuration will include a suite of financial analysis tools and a one-year subscription to an online service for accessing real-time financial data.
Let’s assume that the original version of Make-Me-Money that was developed is the best configuration, so creating the other two configurations will primarily involve the removal of certain functionality. Other differences between the configurations will include the use of different splash screens and help files, and a re-branding of the product name in the user interface to indicate the configuration (good=Basic-Edition, better=Standard-Edition, best=Deluxe-Edition).
The process of creating the good and better configurations starts with the duplication of the code base. This will be accomplished using a file revision control tool in a semi-automated fashion. While different tools may handle this process more efficiently than others, for this example, it is expected that the code base duplication will require one hour of preparation and one hour of revision control tool processing for each configuration.
Since the new configurations will contain a subset of the functionality of the original configuration, unnecessary files will be removed from the new code branches after the duplication process is complete. Depending upon the type of files involved, and interdependencies between files, the removal process could be rather involved with significant changes to makefiles, elimination of source code references, alterations to build scripts and modifications to installers. All told, this process of stripping down the functionality takes about 40 person-hours per configuration.
The next step in the process is to create the customized resources necessary for the new configurations. This includes graphics work to create new splash screens, documentation work to draft new versions of the help files, and UI resource work to re-brand for the new product names. Additional build and installer work will also be needed to incorporate these customized resources into the builds and installers for the respective configurations. These activities consume about 80 person-hours per product configuration.
Before the new configurations are ready for testing, they must be built. Recall that each build takes about 4 hours to run, and we now have three configurations that must be built independently. If only one build machine is available, then the three configurations will need to be built in series taking a total of twelve hours. Alternatively, if multiple build machines are available, then the configurations can be built at the same time.
The Quality Assurance team typically has a set of tests designed to exercise all of the functionality of the product. For them, each configuration is like a separate product and requires a separate set of tests. The process of creating the separate tests will be similar to that used for creating the separate code branches. It will involve making duplicates of the tests, removing those tests that are not needed for the configuration, and tweaking the remaining tests to handle the changes made in the new configurations. This test preparation process takes about 40 person-hours per configuration.
When the testing actually begins, there are now three distinct products to be tested, so the test execution time will be nearly triple what it was for the single original product. Each test sweep of one product takes 20 Quality Assurance Engineers a full day to complete, so now with three products, the test sweep cycle is extended to three days. Given that the three configurations all derived from the same original code base, it is likely that many of the same bugs will be found in all three configurations. The QA Engineers will thus write up nearly three times as many bugs. The Project Managers will have nearly three times the number of bugs to review and assign, and the Software Engineers, Build Engineers, Install Engineers, Tech Writers and other contributors will have nearly three times the number of bugs to respond to.
When it comes to fixing bugs, it is not three times the amount of work, thanks to the capabilities of the file revision control tools. These tools make it relatively simple to apply the same change to multiple code branches. In some cases, it may involve a bit of manual work to resolve conflicting changes, but in most cases, the tools can handle the process automatically. Overall, the work involved in integrating a change to multiple code branches is about 10% of the original bug fix effort per code branch.
Following is a summary of the effort involved in handling multiple product configurations using the code-time PCM pattern:
|Worker Time||Machine Time||Work Description|
|1 hour||1 hour||Duplicating code base|
|40 hours||Stripping out unnecessary files/functionality|
|80 hours||Adding customized resources|
|40 hours||Test preparation|
|161 hours||1 hour||Sub-total – configuration set up effort|
|4 hours||Time required to build configuration|
|160 hours||Testing time for 20 QA Engineers for each sweep|
|16 hours||Time for 20 Software Engineers to integrate bug fixes|
|176 hours||4 hours||Sub-total – Test/fix cycle|
|1921 hours||41 hours||Total effort assuming 10 test/fix cycles|
As you can see, the amount of time and effort required to create and release additional configurations using the code-time PCM pattern is extremely large. This pattern is not normally a viable choice if more than a few configurations are to be supported, as the effort involved scales up in nearly direct proportion to the number of configurations. It can be a suitable pattern for small-size products, or where the differences between the configurations are substantial relative the size of the code base. It can also be used effectively for isolated portions of a code-base that meet the criteria for small size, or substantial differences between configurations.