Did you forget your: Username / Password ?

Microsoft

TechWell

Home

CM Journal Articles

Grokking Change

Written by Ben Weatherall

Monday, 22 June 2009 11:23

This month's topic is "Change Control or Control of Changes." This implies that these are two distinct things, or at least two distinct ways of looking at this critical function. So after a lot of personal angst, I decided to take both tacks and see how they could be brought together.

Typically, "change" is used in relation to code, documentation or requirements. The form most commonly used is "to transform" from something to something else. But we deal with other things that change all the time; things such as processes and procedures, tool chains, and development methodologies. We talk about "Continuous Process Improvement" which also mandates that "something changes." So let's tackle the easy things first.

Changes to Requirements and Code
In his article, "A Requirements Bigot looks at Configuration Management ," Carl Singer discusses how requirements should be treated as code. They evolve over time and different individual requirements have product release oriented scopes. Each requirement may indeed contain slightly different content depending on the release it is targeted for. This is one of the major reasons that CM became involved in Requirements Management in the first place; so that we could track the variants and changes to individual requirements and "build" targeted requirement sets upon demand. Most of the Requirements Management tools available today allow for the branching and merging of individual requirements within a controlled repository of some kind.

Documentation other than requirements follows the same pattern. They biggest difference is that the "containers" are often binary files that do not allow merging of their content.

And then there is code. For the most part, code is ASCII or Unicode in nature and can be merged with commonly available tools. It is interesting to note that the few attempts to develop languages/tools that are not in one of these two formats have, for the most part, disappeared over the years even if they eventually incorporated a way to "externalize" their code (for example: PowerBuilder and Gupta).

The CM perspective is that even though the container type may dictate different Version Control (VC) tools, the basic method of handling changes is the same. Something is created, added to a repository, branched for variant management, merged when appropriate, moved around and/or renamed and eventually "removed" if no longer needed. This provides a way of tracking the Who, What, When and Why of each change. It also provides a way to recover each variation and to link instances of multiple items together to form Baselines (or whatever we are calling them today).

Changes to Development Methodologies
Over the years I have been involved in many changes to the way code development is performed. It always starts with a "Better Way of Doing Things" that someone has come up with. Each method has seemed to be better than the last - and does seem to address failures in the previous method of doing things. Methods I can remember off the top of my head are Waterfall, Iterative Implementation, Functional Decomposition, Top Down Implementation, Bottom Up Implementation, Rapid Prototyping and now Agile. As we transitioned from one methodology to another, change was necessary - both in the way we did things and in the way we thought about things.

From a CM perspective, very few of these required significant changes to either tools or processes. The biggest changes occurred when we went from Just-In-Time check-ins to Check-In-Early/Check-In-Often, and then changed back. When organizations were trying to get to SEI's CMM level 3 or 4, they would change the check-in and tagging policies. Quality Assurance (QA) could then do root causal analysis to determine what types of coding practices caused the majority of compiler faults, logic faults and requirement misunderstandings. But the biggest change was to what was tracked in the Defect, Issue and Enhancement Tracking (DIET) systems. Everything became a controlled record! When Issues were raised, they would be entered and their resolution could well involve creating related defects and/or enhancements against requirements as well as code. Implementation Planning used the DIET system to both determine what needed to be done and to assign the work to be performed. A transition from VC to DIET as a critical management interface occurred.

The advent of Agile methods, especially when used with large distributed teams, has caused a significant change in CM's focus. First, Agile seems to be mostly involved in Java-based projects. This means that Version Control tools that have historically done a good job are no longer sufficient - they must be able to support deep paths, "refactoring" (move and rename instead of remove and add), directory versioning and enhanced merging (e.g. knowing that a change to dir1/foo in one branch/stream should be merged with dir2/bar in a second branch/stream and may indeed have a common ancestor of dir3/foobar). Once this had been addressed, the DIET tools had to support backlogged records that can be sliced and diced in a variety of ways. This turned out to be not too difficult, but tool upgrades that had been postponed for far too long had to be addressed.

The really big change came in the area of Build Management and the advent of Continuous Integration (CI) builds. Prior to Agile, daily or twice daily builds were considered more than sufficient. Quality Control (QC) could not take more than this for testing anyway, even with the use of most available automated regression testing tools. CI builds needed to be performed whenever code was checked-in and only the parties involved notified of its success or failure. Builds went from 1 or 2 per day per branch/stream to potentially hundreds per day. And they need to be faster. Regardless of how long the daily builds took, the CI builds needed to be under 5 minutes.

Now we are talking about physical infrastructure changes as well as new tools that support high bandwidth connectivity, build farms, distributed and parallel builds, incremental vs. full builds, etc. One of the "old" goals of Build Management was to get the developers to use the same build infrastructure (ant scripts, make files, tool chains, etc.) as CM did. Now, controlling changes to the build scripts is critical as is compatibility with multiple front ends (e.g. IDEs as well as the Build Management System).

Changes to Processes and Procedures
Changing a development methodology will of necessity cause a change to both processes and procedures for all parties involved. There are other causes of change, however - the previously mentioned Continuous Process Improvement being a prime example. The goal of these changes is very similar to that for code; to make it match revised requirements, to resolve defects in implementation and/or to increase overall quality and/or efficiency.

Process changes affect what is done, when it is done, who does it and how it is done. Procedural changes affect the tools and the way they are configured and used. From a CM perspective, there is always a need to review proposed changes and to raise concerns when they could adversely impact the stability, maintainability or buildability of a product, or if they will incur unplanned costs to implement. As an example of this last, consider the case where historically most of the development occurs on a "trunk" or mainline with only a few maintenance fixes occurring on branches. The transition to supporting 10 parallel development efforts off of a common, pathologically connected codebase may require new VC tools or at least new merging tools. In addition, there will be additional administrative overhead costs. It may be that these costs are acceptable, but CM should raise them if they have not already been factored in.

I mentioned that CM should be concerned if a proposed change to either process or procedure could adversely impact the stability, maintainability or buildability of a product. When these concerns are brought forth, they should also include a discussion on what changes CM could attempt or what alternatives CM could propose to minimize the risk. CM should always try to have something positive to offer when they say "No" and they should listen to the counter-arguments in favor of the proposed changes.

Change Control
Change Control is both a process and a mechanism to control the changes that are made to a product. There are two ways that change can be controlled:

Changes must be approved before they can be made, and
Only approved changes can be accepted into the (pre-)production codebase.

The difference between these two ways is one of "when" a change will be approved. I have even been involved with organizations that use both of these; pre-approving Development (or Requirements Engineering) to perform work on a defect or enhancement, then deciding if or when to accept the changes into the production codebase.

This is a throttling or bottlenecking mechanism and is intended to prevent both scope creep and to prevent more changes being made than can be tested in the time allowed.

Note that the only valid reason to make a change is to make a product (more) profitable. Each proposed change should be evaluated against this one rule.

Control of Changes
Control of Changes is the mechanism used to accept and prevent changes in the codebase. Typically, it involves, at a minimum, an integration of VC and DIET tools so that all changes have to be associated with at least one DIET record. Of course, without suitable review (audit), there is no way to guarantee that someone did not make undesirable changes and attach them to an existing DIET record, but at least the traceability is there to allow a review/audit to be performed.

That means that Control of Changes is also an oversight or management function that is facilitated by CM. What is to be done when violations are detected is definitely a management function and goes back to policy and process.

Grokking in Fullness
Change, like most words in the English language, has many meanings. Here, we have discussed a few of them as they pertain to Development and CM. Like most things, the concept of change is circular in nature; which means we can start at any point and eventually cover the full circle. There are many ways to prevent change from occurring, from the simple "Don't do that!" to restrictive tool automation. There are also many ways of detecting when a change has been made and what the change was, so that it can be backed out.

Acceptable changes are what the organization decides they are. They should always cause a positive return on investment in either the perception of product/company quality or directly in product revenue, but they may not.

As CM'ers, we have to remember that change is why we exist and helping others make good changes is how we stay employed. So I will close by saying, "May all your changes be well thought out and perceived in a positive light!"

Ben Weatherall is currently based in Fort Worth, Texas where he practices Practical CM on a daily basis supporting a modified Agile-SCRUM development methodology. He uses a combination of AccuRev, CVS, Bugzilla and AnthillPro (as well as custom tools). He is a member of IEEE, ASEE (Association of Software Engineering Excellence – The SEI’s Dallas based SPIN Affiliate), FWLUG (Fort Worth Linux Users Group), NTLUG (North Texas Linux Users Group) and PLUG (Phoenix Linux Users Group).

Set as favorite

Bookmark

Email this