The Virtues of Version Control

“History is the version of past events that people have decided to agree upon.” — Napolean Bonaparte

It’s always a good idea to maintain a network of colleagues that you can call on for advice when you need it. Recently a friend and I were discussing our respective software projects, and I started asking him questions about his methodology. I asked if he was making use of any continuous integration systems, like Hudson or CruiseControl.rb. He wasn’t. I asked him if he had used any tools for coverage analysis, like rcov or NCover. Neither was he doing any similarity analysis (Simian) to identify code violating the DRY principle. I asked him what he was using for TDD/BDD (check out Cucumber), and he replied that he wasn’t doing any.

Many software teams I’ve encountered (or even been a part of) have ignored these tools. This isn’t terribly uncommon. Finally I ask him, “are you even doing any version control?”. He was not.

I found this to be very surprising, because my buddy has been working on his project for the better part of a year. He hopes to productize his software and take it to market. It’s apparently a fairly mature code base, and yet it is not under the safe watch of any versioning system. It’s shocking to me, because here we are in the year 2008. Today’s software engineering tools are more powerful than ever before, but to a large extent they go unused. Why is this?

With regards to versioning, my friend has several options. Traditionalists are still using CVS, and Subversion is still quite popular. Microsoft has its line in the water with SourceSafe, which I think has been integrated into TeamSystem, but I’m not quite sure. Even some of the strongest open source advocates I know readily plop down cash for Perforce, they say it’s THAT good. There’s new entrants to the arena all of the time, like Eric Sink‘s SourceGear. Linus Torvalds uses git to help manage the development of the Linux kernel.

My buddy’s reason for not using any of them? “I’m the only person working on the code. Why would I need to version it?”

I believe this is the most common reason for not using a versioning system — people just don’t know when the project is established enough to merit using one. Many less experienced developers feel that the right time to start using version control is when there are multiple developers touching the codebase. While this would certainly be a good reason (and I can’t imagine many successful teams of developers not using versioning), it’s flawed reasoning that the lone coder working in isolation doesn’t benefit from the virtues of version control. My take on it is that you should be using version control as soon as you have code that you care about enough that you would be disappointed to lose it. That’s when it’s important enough to version it.

All of this of course inspired me to climb up on my soapbox and preach about the many reasons for versioning your software. So here are my Top 10 reasons for using a version control system:

1. Never again suffer from the confusion of juggling multiple versions of your codebase by hand.
2. Provides a single source for backups.
3. Multiple developers easily work against the same code base.
4. Branches are easily managed with version control. Sometimes you want to experiment and take the project in a whole new direction.
5. Commits can reference ticket numbers or bug ids so that developers can easily answer the question “when did we fix that bug?”.
6. Easily diff new versions against old ones to pinpoint changes.
7. Easily integrate with a web tool like Redmine to provide project statistics at a glance.
8. Plays a key role in continuous integration systems.
9. No real software engineer or manager will take your project seriously unless it’s under version control.
10. Develop with impunity. With version control you’re like a trapeze artist flying worry-free over a safety net.

For these reasons, I believe that just after the compiler/interpreter and debugger, a versioning system is the most useful weapon in the software engineer’s arsenal. If your project isn’t under version control yet, what are you waiting for? Here’s a nice tutorial and a cheat sheet for git to help you get started. Once you’re up and running, you might want to check out Gitosis (do it yourself) or github (managed hosting) to share your repository with the world.