I remember it clearly. It was about 10 years ago, during the .com boom. A new telecom startup had lots of money. They wanted to do CM the right way. So they bought the most expensive tools and hired consultants to configure and glue things together. Three months later they were still working at integrating CM with Problem Tracking, the way they wanted it. That company went belly up quickly. From the ashes, a new company was born. The founders didn't want to make the same mistake. After letting them view a different solution for a few weeks, I went in there and in 3 days had the team trained and working on a solution that already did what they were trying to do and a lot more. In 3 days, all of their data (from the previous company) was loaded in and users were trained to support and use the system. The solution cost: about the same as they paid for their 3 months consulting previously, and far less than their previous licensing costs.
Mistake #1: We assume that the most expensive, or most prevalent solution is the best
Why is this not the case? Is Windows the best? It may be getting there, but the Mac has put it to shame over the last quarter century, even though Mac's market share remains low. (By the way, I'm not, and never have been, a Mac user.) What about rockets? A little company (less than 1000) named "SpaceX" is raising eyebrows as it promises to lower the cost to space by an order of magnitude, with it's first successful launch last year and it's heavier lift vehicles targeted for this year.
CM is a complex business. The market leaders got there by carving out a niche and growing market share on it. Maybe its freeware (CVS), COTS packaging (PVCS), virtual file system (ClearCase). Whatever the reasons, these have captured market share. But don't make the mistake of assuming the market leading tools are the best. Look around and you'll see more able, more reliable and less costly, and less risky, solutions. Just as for CVS, SVN goes one better, the same likely holds for any solution that is not delivering.
Branching Strategy is Key
On another occasion I was exposed to a project while they were deciding on where to go from their current CM solution. They needed to work in a multiple site environment and they were taking the time to make sure that their revised branching strategy was going to work. They had spent a couple of months on it and had a strategy in the review process, but just weren't yet sure how well it would work. They did know that they would have to spend some time training the staff in the strategy and implement some quality controls to ensure that the strategy was being followed properly. In the mean time, another company about the same size, needing to work in a multple site environment, had a very simple release-based branching strategy with exclusive checkouts. It took them virtually no time to train staff and they used the tool to enforce the strategy.
Mistake #2: We develop ever more complex branching strategies to deal with ever more complex CM.
Why were these two situations so different? More than likely, the reason is one of process and one of matching technology to the process. The CM world invented branching almost 40 years ago. It allowed them to work on the next release in parallel with supporting the current one. It was and is a great concept and a valuable tool. However, processes evolved that said:
- We need to provide a common support area for our developers.
- We need to track various testing promotion levels.
- We need to keep files associated with a single change together.
- We need to track parts of a change according to who made them.
- We need to keep track of baselines and specific builds.
- We need to have multiple variants of our baselines.
It's good to see process evolving. But when the technology doesn't evolve as well, guess what happens. Well two things happened. The first was the invention of the "MAIN" branch. The second was the overloading of the branching concept with a myriad set of reasons and the addition of labelling technology to help to sort out the mess caused by this overloading.
I know there are two camps out there: MAIN branch, and main-per-release branch. I hope there won't always be. Why is there a MAIN branch camp? Because we sculpt our tools to support it. However, however well we sculpt, a MAIN branch solution