As I talk to people I am very surprised at the lack of importance attached to source control in some development organizations. It seems that many teams either do not use it at all, or developers do not see why they have to understand it. The common theme in my experience is that managing the source base is typically someone elses problem and that developers commonly think that their job is only to produce the code, check it in, and move on to the next thing.

I believe that developing the ability to use a source control system and understanding the underlying concepts enough to use them effectively is a core skill set that every developer should posess. Every developer on a project should understand the general concepts of branching, merging and tagging needed in order to perform development concurrently and still keep the code base consistent.

Languages are pretty easy to learn in general once you know one. They mostly consist of a base set of constructs you have to know in order to use them effectively. Once you learn one ‘if … then … else’ construct, you can pretty much generalize it to learn the concept in any language (Lisp might be an exception here, since I’m still not getting it). In the past, I’ve seen developers commonly focus on learning nuances of the languages they already know, or even the latest IDE, rather than improving their skills at a higher level by learning to manage the code they are producing, which can bring a development organization to a whole new level of effectiveness.

Now, to be fair, I’ve only adopted this viewpoint over the past 3 years. Before that, I didn’t want to know anything about something as boring as Software Asset Management. We had “people” to handle that. I just wanted to know what to check out and who to talk to when it had to be merged somewhere. I have found that this shift in my thinking has been the most valuable one that I have experienced in the last 16 years in software development. The ability to manage code at a change level, while creating the traceability necessary to find problems that are related to discrete changes quickly has been an invaluable tool for me in the last few years.

There are some great books on this subject, one of which is Software Configuration Management Patterns: Effective Teamwork, Practical Integration by Stephen P. Berczuk and Brad Appleton, which explains many of the common patterns used in Source Management.

So, the obvious question is, “Where do I start?”. The first place to start is to make it your personal responsibility to learn the concepts and be able to apply them. This doesn’t mean doing everything “by the book”. Take the concepts and make them your own. Throw away the things that do not work for you or your organization now, and use the things that do. Implement the concepts in manageable “chunks”. Most likely, some concepts just won’t work now because your organization is too immature to make them work, so keep them in the back of your mind. You’ll grow into them.

Set up a version control repository and start playing with it. I recommend Subversion. The Subversion tool can be found at http://subversion.tigris.org. O’Reilly Associates recently published a book called Version Control with Subversion that is also available for free online if you don’t want to pay for it. You can read the book here.

The bottom line is that these skills are something that can increase your value immensly in an organization because, like me a few years ago, not many people feel the need to learn them.

In a future posting, I’ll describe setting up an automated build system using tools like Subversion, Ant, and CruiseControl. An automated build system, and implementing the concept of Continuous Integration is a really good way to get a handle on the change in your development organization.