Sunday, December 17, 2006

SCM vs Software Development

I came to the realization a while back that I'm not really an SCM person. In fact, I'm a software development process person who has been focusing on SCM. That's probably why most of my posts lately can't be directly linked to SCM. I've been working on broadening my thinking. As a result, I've decided to change the focus and title of this blog from SCM to Agile Software Development.

I think there's a lot of value to be realized using top-notch SCM tools like AccuRev, ClearCase, Perforce, and others. But I've come to the conclusion lately that a lot of the value of these tools either sits on the shelf as potential value or goes unrecognized and unappreciated. I think there are two reasons for this. First, I think that most people think of SCM tools as a repository and nothing more. Second, most SCM tools are optimized for being repositories and nothing more.

To put it another way, I've decided to turn my emphasis upside down. I don't think that most developers show up for work thinking about how best to optimize their branching and merging. So, instead of starting there and ending up at the developer benefit only to find that the audience has surfed to another page, I've decided to always start from the developer's point of view and link the discussion back to SCM only when necessary.

This also gets to another point. SCM folks by and large already recognize most of the value of SCM tools. That's what they do all day! Whereas, developers prefer to just write code all day and keep their interaction with an SCM tool to a minimum. That is as it should be. As a result though, I don't think that developers are getting the full value out of their SCM tools. I'm not saying that developers are thick, just that their focus is on writing code, not playing with SCM tools on the off chance that they might stumble across something that will increase their productivity.

Thus, it is up to folks that do think all day about how to improve developer productivity through better SCM tools to make the extra effort to pitch things from a developer's point of view so that when a developer does come up for air they see right away that they are being offered a lifeline and not a lead weight.

4 comments:

Anonymous said...

I couldn't agree more. People often talk about the object-relational impedance mismatch, but it often seems to me that there's a development-SCM mismatch. This is especially true with older CM tools that CM tools are lagging behind. The tool that is chosen seems to have such an impact on how development is done. For example I've recently had to use CVS for a client and re-factoring is just a nightmare.

All is not lost though. I do think that configuration management is increasingly championed now. If the open-source community's adoption of distributed cm systems is anything to go by (like the Linux kernel) then there is a growing realisation that the tool must fit the process: normally triggered by the trauma of previous merging accidents.

Recent research I think is interesting--- if it works--- is a project I read about from Iowa University Molhado and MolhadoRef. Is this the future of Software Configuration Management?

Abercrombie and Fitch said...


welcome to our shop,my shop website is hollister milano and Abercrombie and Fitch and Abercrombie and

Fitch UK
and Diesel Jeans UK .

Automaty Online Sizzling hot said...

so true!

Ethan Moore said...

Nice Article!! I agree that most developers show up for work thinking about how best to optimize their branching and merging.Scrum development projects welcome change by using small development cycles that incorporate customer feedback on the project’s deliverables after each Sprint.For more, Please Follow: https://www.scrumstudy.com/blog/is-change-accepted-in-scrum/