It struck me the other day that the way I use source control is very similar to how I play video games – specifically, when and how I save my game. I like to use source control as a safety net – it’s a way to keep track of a place I may need to return to. It allows me to continue on with my work and not be worried if I go down a wrong path. I can always revert and be right back where I started.
Taking this one step further, we might say that the quick save in a video game is like a commit in source control. Saving your game with a specific name is like creating a branch.
Let’s say I just finish taking out a whole horde of zombies (Left 4 Dead anticipation is infiltrating my blog). I’ll probably do a quick-save to make sure I don’t have to re-play the same encounter again. This is just like committing some code you just finished. You’re saving your current progress to make sure you don’t have to re-write the same code twice.
Now, back to my game, what if I come to a fork in the road. I can go left through the ominous looking sewer, or I can go right through the abandoned city. Well at this point I’ll go and save my game with some sort of name like “Taking the sewer”. That way I can continue playing, quick-saving as I go, but I can always get back to that fork if it turns out I made a mistake.
This is very similar to creating a branch in source control. You want to start working on something new, or something experimental, and you need to be able to save your progress as you go, but you always may need to go back to that original point.
I find that many developers wait too long to commit their changes. The more frequently you commit, and the more organized you are about it, the less you have to worry about keeping track of every change you make. This means you have left cruft floating around in your mind to remember and you can concentrate on writing good code. I think if developers think about source control the same way they think about saving their game progress, it would help them get into the habit of committing frequently and branching appropriately.
Nub | 15-Nov-08 at 10:14 am | Permalink
Am I the only one who, upon reading the title, thought this would be something about highscores in terms of number of commits?
Good article, I absolutely agree. I used to do the same thing on “Below the Root” back on the Apple IIc — omg I am old.
Justin Lilly | 15-Nov-08 at 11:28 am | Permalink
I really like the point you’ve made here. Haven’t really thought of branching in that way.
I can’t help but be reminded of playing through mike tyson’s punchout on my NES emulator. I would save game state after every successful punch so I could quickly revert if something went wrong. A bit of cheating, but a fond memory
Successful Scrum | csixty4 | 15-Nov-08 at 12:42 pm | Permalink
[...] I talk about the need to treat the less fun aspects of programming like rituals. For example, treat checking code into source control like saving in a video game: Now, back to my game, what if I come to a fork in the road. I can go left through the ominous [...]
Marius Gedminas | 15-Nov-08 at 3:37 pm | Permalink
There are games where you can save at any point. That doesn’t work well with code: you should only be checking in working code. Perhaps a game that has specific save points and won’t let you save at other times would be a better analogy. On the other hand, that might leave you checking in not as often as you should be.
I prefer to look at source control as a game in its own: find the smallest self-contained meaningful code change on the way to whatever you’re trying to achieve, then commit that.
Shawn | 15-Nov-08 at 4:00 pm | Permalink
I agree on commit often but I think “quick-save” is a poor analogy. Commits should be more like checkpoints. Places to return to after you’ve met a certain condition (fixed a problem, updated code, etcetera) rather than when you think you might break something. There should be a milestone, however small it may be.
JLR | 15-Nov-08 at 11:08 pm | Permalink
You know, this actually helps.
I already commit often, but somehow thinking about it this way makes things clearer. I think this will help orient me when using version control.
Thanks for taking the time to write it up!
Joe the Killjoy | 15-Nov-08 at 11:58 pm | Permalink
The tricky part is merging the savegames…
João Marcus Christ | 16-Nov-08 at 5:36 am | Permalink
“The more frequently you commit, and the more organized you are about it, the less you have to worry about keeping track of every change you make.”
If you’re using SVN and only commiting “production-ready” code, it’s not possible to commit ofter. What, you never heard of companies that don’t have any kind of automated testing, test plans, or even test/staging databases and application servers?