Editorial Note: I originally wrote this post for the SmartBear blog. Head over to their site and check out the original. While you’re there, have a look around at posts by some other authors as well.
I can think back to times in my career that the source control that I was using (or not using) made me a cranky, unhappy human being. Years and years ago, there was the time that a coworker accidentally left all of the files in the codebase checked out through Visual SourceSafe and went on vacation. I distinctly remember enlisting a sysadmin and the two of us going into the source control server with admin credentials and hacking at settings until we could undo that and I could work. You see, Visual SourceSafe employed a pessimistic locking strategy by which his checkout meant I couldn’t do anything with the code.
There was also the time, a few years later, when I was suffering through a project that used Rational Clear Case. On a normal day, delivering code to the official branch or stream or whatever took half an hour. If I had to work from home, it took all morning.
And then there was the time that I was switched onto a project with no source control at all. The C source code was stored on a production server — a production server that controlled physical machinery in the real world. To “check things in,” you would modify the C code, turn off the physical machine, load the modified kernel modules, turn the machine on, and then revert real quick if things started blowing up. I’m not kidding. This was the commit/rollback strategy when I arrived (I did actually migrate this).
Tools Affect Behavior
These things make for fun war stories, but they also serve to illustrate how source control dictates behavior. With Visual SourceSafe, we implemented some kind of out of band email protocol to remind people to check in. With Rational Clear Case, I implemented a homegrown SVN for day to day version control and delivered/integrated only a few times per month. With the machine server, there was extensive historical commenting in every single source file. These tools spur you toward behaviors, and, in these cases, toward wasteful or bad behaviors.
For the examples I listed, I was steered toward useless process, steered away from continuous integration, and steered toward neurotic documentation. But the steering can apply to almost anything, and that includes having a healthy code review process.
There have been studies conducted that demonstrate the importance of code review. It is uniquely effective when it comes to catching defects earlier than later, and it promotes collective code ownership, thus reducing “bus factor.” I could go on, but let’s take it as axiomatic in this post that you want to do it.
Does your source control situation make it easy for you to conduct code reviews? Or does it discourage you, making life tough if you do them, and thus making you less likely to do them. If it’s the latter, that’s not a good situation.
Read More
