Did you forget your: Username / Password ?

Microsoft

TechWell

Home

Behaviorally Speaking

Behaviorally Speaking: Merge Mania!

Written by Bob Aiello

Friday, 31 October 2003 16:00

I am scared of merging code! I am scared of branching, because I will probably have to merge the code back later. Yet branching and merging are two of the most important techniques for Variant management – which is an essential skill for CM Practitioners (and most developers as well). Usually, CM gurus are asked to define the branching model and then troubleshoot when developers have obfuscated things beyond recognition. I have often found myself getting bullied into adopting a complex branching scheme that I know (from experience) will break from time to time. How much is enough to get the job done? Where should you draw the line when deciding how to use branching and merging in your applications? Read if you’d like to compare some notes on best practices in order to establish Just enough merging complexity to get the job done and yet avoid human error!

The Cognitive Factor

Earlier today I was teaching a class in ClearCase for experienced technology professionals at my company in NYC. I often enjoy the candid feedback from my colleagues in the form of written evaluations. One of them today mentioned that I was able to make complex concepts easy to understand (and keep the class awake with my own brand of jokes and stories!). I always teach the importance of understanding a CM repository as a three dimensional source code vault that allows the developer to go into a “time machine” and see the environment exactly as it was when the production release was created. I go through lots of examples of branching and merging strategies that are simple and yet powerful enough to solve the problems that our developers must address on a day to day basis. Some of these concepts are pretty complex and many people may have trouble understanding them completely. It’s my job to find a way to make required information as simple and clear as possible. It doesn’t do any good to have a world class process and methodology if the developers can’t understand it within a reasonable period of time.

The Dangers of Complexity

Some of these concepts can be cognitively difficult to understand. What’s worse is that sometimes one member of the team will insist on creating a branching strategy that is overly complex. It will work – it might even be quite powerful. But the rest of the team will have a very hard time understanding what is going on. On the other hand some problems are complex themselves and require appropriate tools and processes to manage them accurately and effectively. For example, cross platform development may require branches for OS customizations that must be done for every release across all supported platforms. Managing this complexity is necessary and often a business requirement.

Financial Services

I work in the financial services industry where the business itself can be very complex. I have worked on projects that have involved Derivatives Trading (e.g. Equity, Bonds). Often the regulatory requirements alone can be very complex and demanding even for experienced developers with strong backgrounds in financial services. The last thing that anyone needs is to be forced to focus on overly complex development methodologies that may be elegant and powerful, but far more demanding than makes sense from a business perspective. The financial services industry is not necessarily the same as other industries (e.g. Medical Systems, Defense and Software Vendors). The SCM function in Military and Medical systems is often well funded and staffed. In financial services we support hundreds of developers worldwide with a two person staff. The CM support group may be very small, but the source code must still be safeguarded and introducing a software defect can result in millions of dollars in losses. (I was involved in incident where the wrong version of a shell script was one of the factors that led to a 1 hour systems outage at the NY Stock Exchange!)

Keeping it Simple

I always advocate keeping branching methods as simple as possible. We use branches for managing bug fix releases (e.g. branching off of a version label). We also use private branches to hide incomplete code that should be checked in to make sure that it is safeguarded, but isn’t yet ready for other developers to see and compile against. One trick is to checkout the file on the main branch and also on the private branch. The file is constantly checked into the private branch (that is hidden from the other developers). Since we’ve also reserved a copy on the main branch we can keep the merges trivial. (If you didn’t reserve the file on the main branch someone else could come along and put some changes into the file that would require a merge.)

Communication is a Miracle

When a developer tries to check out a file and learns that someone else has it reserved he can either check it out unreserved (which will likely require a merge later) or even better he can call the person who has the lock on the file and ask him when the file will be checked back in. I emphasize that it makes sense to pick up the phone and check with a colleague before creating extra (often unnecessary) work. Too often technology professionals miss the importance of good interpersonal skills and team cooperation. One reason that I dislike CVS is that it is an “unreserved” checkout model that requires lots of merges. I’ve seen this result in mistakes and therefore software defects.

The People Factor

Considering the people issues including cognitive complexity and human interactions in any technical process is essential. Too often technology professionals are so focused on the software issues that little emphasis is placed on the people who must use and support and the technology. If you consider these issues in developing your branching and merging methods you will be successful and effective!!

Bob Aiello is a Senior Editor for Crossroads News and an Associate Director at a major financial services firm in NYC, where he has company wide responsibility for Software Configuration and Release Management best practices. Bob is on the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he is also the chair of the CM SIG which meets in Midtown NYC. Mr. Aiello has a Masters in Industrial Psychology from NYU and a BS in Computer Science from Hofstra University.and Release Management best practices. Bob is on the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he is also the chair of the CM SIG which meets in Midtown NYC. Mr. Aiello has a Masters in Industrial Psychology from NYU and a BS in Computer Science from Hofstra University.

You can reach Mr. Aiello by email at raiello@acm.org

Set as favorite

Bookmark

Email this