blog-j: Symbolizing, Coding, Objectifying, Processing

I bumped into a friend of mine on the way into work this morning. I’d heard that she’d recently started a new job (really, I’m a Facebook stalker…much easier to keep up with friends like that - no need to actually have a conversation…), and I was curious how it was going. Her reply (paraphrased):

“It’s been a switch moving to an [Advertising] agency. They don’t even have source control! And I only have one monitor - it’s killing my productivity!”
Name withheld to protect the innocent…

Let that be a lesson to you.

Really, if you aren’t using some form of source control, you’re in trouble. And do not make the mistake of confusing source control with backup: the intent of backup is to ensure that you always have a certain entity, be it a file, a set of files, perhaps an (il)legally downloaded music collection. Source control isn’t concerned with the whole, final product; its intent is to capture change. Hopefully, as a developer or designer or hybrid, you see the value in that. If not, if you haven’t been bitten by this particular dog, I’d recommend you start using source control and avoid it entirely.

You see, developing a product, be it a website, mashup, game, desktop app, what-evah, is an iterative process. You go from A to B to C to D. You’re always in flux, always moving, incorporating new ideas, recalibrating, learning and relearning. And one day you’re going to break something that worked fine yesterday. Or have a client tell you they liked it the old way. Hell, you might like it the old way yourself! And then, boom - your ever-overwriting backup strategy goes to hell. You’re stuck going back to figure out what the hell you did to have it work the way it did before. With source control, you can simply roll back or merge the old with the new (well, hopefully simply…).

Now stop being selfish and thinking only about yourself. Most of us don’t live or work in a vacuum, after all. You’ve got multiple people working on the same set of files. To quote the Big Bang Theory, “I believe the appropriate metaphor here involves a river of excrement and a Native American water vessel with out any means of propulsion.” Overwriting other team member’s changes, losing your own changes, it’s a nightmare.

Really. I’ve been there.

So do yourself a favour: set yourself up with source control. First day at the new job, and they don’t have it? Set it up. Quit if they don’t let you. What to use? Lucky for you, you’ve got lots of choices. Microsoft shop? Use VSS. (Ok, that’s a joke…if you can afford it, and really have the need, pick up Team System.) Set your team up with SVN (and, if you’re on Windows, grab Tortoise - you’ll thank me). Find a plugin for your IDE of choice (you do use an IDE, right? sadly, there’s no SVN plugin for FlashDevelop that I know of - yet - but working with Tortoise makes it relatively easy). Go to town. Don’t have your own server or infrastructure to install on? Use unfuddled.com - an excellent project management and collaboration tool that includes both SVN and GIT, along with a suite of other tools for you and your team.

So there you have it. Many have said it more eloquently before me, and many more will say it better (Jeff Atwood of StackOverflow.com fame, for one). But if you’re reading this, forget about how horrific my prose is this evening and get yourself some source control.

(Don’t even get me started about how bad email is for communication…set yourself up on a collaboration platform and get the important crap out of your inbox…)

(Ok, I really think I’ve put off doing my timesheets long enough…bags…)