As an industry, SCM is conservative – we hold the corporate jewels in our hands and we are reluctant to let either processes, procedures or personnel have a chance to mess them up. In fact, when they do get messed up we tend to lose our jobs. Then along came Agile and the need to support it while maintaining both technical and professional integrity.

At first the battle was to keep SCM in the picture at all as many development organizations tried to get rid of anything that slowed them down. Versioning, branching, merging and defect tracking all impacted their productivity, so they pushed to have them removed from the process just like they did for formal requirements and documentation. We fought back with varying amounts of success. Bloodied and weary, we finally got to the point where development agreed we were necessary. My favorite quote went something like, “there are many necessary evils in the world – and you are indeed evil!”

I think the turning point was when Continuous Integration, and its associated builds, came into fashion. Agile has matured along the way and picked up some of the processes and procedures they had previously disdained. These included versioning, branching, merging and defect tracking. They often wanted new tools to support the “new, Agile way,” even though in many cases the existing tools were capable of meeting their needs. Some of the practices did change our requirements; things like refactoring. Some of the old versioning tools could not handle merges of codebases where one or more of them had been refactored, so many of us had to rapidly switch tools. This often required a lot of hidden work to get triggers, wrappers, interfaces, metrics data collection, etc. working with the new tools. At the same time, there was a push to use tools that supported such things as backlogs and user stories instead of “just” defects. It was often the case where a development organization would bring in their own tools and tell SCM to either use them or get out of the way.

All of a sudden SCMers had to start rolling out their own tools, integrations, customizations, etc. with a speed even greater than the typical Agile development organization. And with significantly less personnel. We now leveraged what we could of the Agile methodology. We did rapid prototyping knowing ahead of time that things would have to be completely redone at a future time. Our assumptions, ones that made sense at the time, was that once a branching/stream structure and new tracking tools were in place to support this new way of developing software, it would stabilize and we could catch up.

For most of us this has not happened yet. There seems to be a tendency by development to take continuous process improvement to a ridiculous extreme. One of the primary tenants of CPI is to measure your process using specific metrics so it is possible to tell if changes are effective or not. Once again, gut feel seems to be considered a more accurate measure of a process change than metrics. I have even heard of processes changing so fast that there is not enough time for metrics to be statistically significant – even if there were time to put them in place to begin with.

The end result of this is that SCM has to adapt and do so at a rate that would have been considered impossible just a few years ago. We must adapt technologically, but we have to maintain the core integrity of principals of SCM: identification, reproducibility and traceability[i]. A typical development sprint team consists of 5 people of which at least one represents the Quality organization. A typical SCM “team” consists of only one person. Across the software development industry as a whole, the SCM headcount is probably only 1-2% of the combined Development and Quality “workers[ii].” For those of you in larger companies or those who are involved in admin-heavy tools, this probably sounds low; but from empirical evidence it is not. This is especially troubling for those who have to support multiple teams who are using different methodologies or variants of them.

So what are we to do as an industry? There are good tools, both commercial and Free/Open Source, that we can leverage. There are many sites, cmcrossroads.com obviously being one of the better ones, that can be used for getting answers to questions and downloading samples, but that still leaves the heavy lifting to be done by the SCMers in the trenches. There is rarely enough time to do it right and even more rarely time to do it over.

I have a proposal for those of you reading this - something that many consultants have done successfully over the years. I propose that we pool our talents, skills and knowledge in a proactive way. That we enable and utilize secure instant messaging and/or a groupware environment where we can peer review each other’s work. A place where we can share documentation, triggers, wrappers, metrics and anything else that makes sense. On average, we do not have the resources necessary to supply a “second set of eyes” on the job – but there are a LOT of us spread out over the world.

CM Crossroads is venturing into the social networking aspect of our life in an experiment to engage us to a greater extent, to foster personal relationships where is it easier to use a back-channel to ask for help. If we can combine this with IM and a SourceForge project, just imagine what we could accomplish as a group.

Trackback(0)

TrackBack URI for this entry

Comments (2)

Subscribe to this comment's feed

configuration management said:

	... Excellent. This is just the kind of exceptional service that many of us early believers and customers expected. Thanks so much for posting this information!configuration management
	report abuse vote down vote up

October 24, 2009
Votes: +0

raj2037 said:

	... I liked the last para and coming of social networking , IM and SourceForge project...will be curious to see how things shape up...
	report abuse vote down vote up

October 22, 2009
Votes: +0

Write comment