from the perspective of a software developer and manager

Source Control: A Good Idea

Source Control: A Good Idea

First, a quick primer on source control or version control systems (VCS) or revision control. A version control system is a piece of software that allows for the storage of multiple versions of files. Here’s a hypothetical situation:

Often in the development world when we’re learning a new programming language, the first application we build in that new language is a program called “Hello World.” It usually consists of one file and outputs the words “Hello World” to the screen or console. Say I started to learn Scala, and started with a Hello World application. I build out this one file and commit it to my version control system. I then decide I want to do some experimenting and I modify my Hello World file to the point where it will no longer compile. Using my version control system, I can revert my file to the previous version and begin again with a pristine Hello World file. From this brief example, I’m sure you can begin to see some advantages of working this way. We’ll go over more of them further down the article.

There are many development shops around that do not have adequate source control systems in place for their developers. I’ve even seen Fortune 500 companies that have large in-house development shops where this is the case. I can only think of a few reasons why this might be.

The cost of moving away from a poor version control system is prohibitive.

The politics/bureaucracy/red tape that must be gone through to make the change are difficult.

The business case for a good version control system has not yet been made.

Whatever the reason might be for not having one, I’m going to propose that if you or your company is developing software, a modern source control system will save you time and money (and frustration, and possibly even developer turnover, etc). This applies even down to the one-man entrepreneurial software development shop. Here are some advantages to a modern version control system:

You can revert code. If you are diligently committing to your source control system, you can revert your codebase to any commit point in the past. This has helped me many times. Here are some possible scenarios:

The code worked fine one day, but not the next. You need to revert to a working version to make the client happy.

The client wants to go back and pull some assets from an old version of the site for new work.

Your server admins say that someone broke the build when they pushed the code to the QA server. You need to find out when the change was made and by whom.

You can share code, easily, among as many developers as necessary, across multiple geographic locations. Even as few as two developers trying to share code across a network drive could easily waste an hour a day while they try to manage the code and not overwrite eachother’s changes. However, with version control, one developer commits, the other developer pulls down those changes and continues to work. Sometimes a code merge may be necessary, but it is highly preferable to the alternative. The time and costs of having more than two developers on a project without version control exponentially increase with each developer added.

You avoid multiple versions of the same file or project on the network share. I’m sure we’ve all seen presentation.ppt, presentationfinal.ppt, presentationfinalrobertmodified.ppt, presentationfinalrobertmodified1017.ppt and similar on a network share. I’ve been guilty of doing it myself when there was no good version control system available. With source control, you have one file, and if you need to revert it to another version, it’s all there for you. No 12 versions of a similar file sitting there confusing everyone.

You can track down bugs more easily. If a bug was introduced in one version of the software, you can go back in time, see which files were updated when the bug appeared, and even check the differences in individual files. This is highly preferable to making phone calls to individual developers who you think might have caused the bug and asking them what files were changed. Source control remembers it all.

Most of the good ones are open source. You can download, modify, update, change, and use the software however you want. As long as you don’t expect support, these products cost only the bandwidth of the initial download, the server to run them, and the admin to maintain them. This is not a new software idea, and the disadvantages that older systems had are all worked out with modern systems.

In the next part of my series on source control, we’ll get out of the theoretical into stuff that can really be applied. We’ll define what I’ve been calling “modern source control” as concrete products. We’ll go over a couple scenarios and make recommendations that will save you time, money, and most definitely, somewhere, sometime, your bacon.

2 thoughts on “Source Control: A Good Idea”

Your coworkers are too stupid to be lazy. That’s a waste of time. All you can hope to do is train your manager. Management should like source control because they like all forms of control. Makes them feel important. Screw the others; fixing the leader is your only hope since you’re not able to replace him. Start networking with other competent developers and either try to get them to join your team when you have an openning or get them to hire you at their shop.