In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
Agile CM Requires Good Software Architecture
If you think that you can ignore your software architecture and still have an agile CM process, think again. I've seen countless architectures where a handful of files are bottlenecks to the whole development process. The same file needs to be changed by virtually everyone. A single file is stretching the limits of your compiler or version control tool. Introducing product variations is causing nightmares in the software. Here are three key things that all projects can do to simplify their lives.
Minimize Contention on Files
Files have high levels of contention because they were designed to have high levels of contention. If I have to put a change number in a single file every time I make a change, I'll expect a lot of contention. If instead, all I have to do is call a routine with my change number, the contention disappears. It has the same functionality, but no contention. Most files which have a high contention on them can be dealt with in this manner. This is true whether it's a change number, a message code, or even a function. Replace the one-file policy with a distributed, less contentious one. You'll also find that your version numbers for the file stay down to earth rather than growing astronomically, and your CM tool may like that.
File Ownership for Quality
Did you ever work in a car wash? How much attention did you give to each car? Now when you're cleaning you're 1972 Mustang do you give it the same level of attention or more? Code is something created. The creator has pride in his/her creation. Don't destroy that pride by making it open season on everyone's code. File ownership does not mean that the owner has to make all the changes, but rather that the owner has the responsibility and authority for the design of that code on an ongoing basis. The owner reviews all changes at a minimum. The CM tool can help support and enforce file ownership, ensuring that the otherwise open season agile process does not degrade code quality.
In the haste to get the product out the door, data is hard-coded into source code files. This may make changing the data more difficult, but the real crunch comes when product variants are produced by having variant files with different values of the hard-coded data. This can be a CM nightmare if there are many variants along different axes. Work from the outset at a strategy to make data run-time configurable. This does not involve more code (usually less in fact), but does require an architectural decision up front to allow data to be run-time configurable. The result is that code is written with that assumption. Allocations are done as required rather than up front, thus making use of changes to the configuration parameters. Variables that can be changed through the user interface are used rather than hard-coded "#define" statements. Slightly different algorithms are used to support some dynamically changing values at system start-up, or even throughout the life of the application, rather than assuming static values. The amount of flexibility not only reduces the CM load, but speeds up the design as the decision on what the hard-coded values should be can be deferred to the product team.
Agile is Just Good Design and Common Sense
Now go through all of these factors and tell me which ones you would not want to take advantage of if you weren't looking at creating an agile CM process. Are you surprised? Agile software development and agile