Version control and me

In 2000, I spent a year abroad. At the time, desktop computers were the norm, and laptops were prohibitively expensive. USB flash drives had literally JUST hit the market, and the cloud was barely something industry insiders talked about. I produced huge amounts of text on computers, however, and the way I transferred it was using 3.5″ 1.44 MB floppy drives. Microsoft hadn’t even started talking about version control features in the Office suite yet, but I had to keep track of what file to hand in to my tutor. In lieu of actual version control came increasingly impossible to deal with naming conventions such as this:

• File.doc
• File.V1.doc
• File.V1.Edit.doc
• File.V1.Edit.Review.doc
• File.V1.Edit.Final.doc
• File.V1.Edit.Final.FINAL.doc
• File.V2.Final.doc
• File.V2.Final.IREALLYMEANIT.doc
• …

Well, you get the picture. It wasn’t good, it wasn’t intuitive, and it certainly wasn’t sustainable. Worst of all, it made it really hard to collaborate with others on digital files, meaning that we’d typically either all work together around a single keyboard, shoulder surfing as we went, or work on our own bits of the project and then attempt to compile the result into a cohesive whole.

Although this is more than twenty years in the past, the practice is still commonplace. Oh, sure, folks might use better, more intuitive naming conventions, but the practice as a whole hasn’t changed all that much for most people. Oh, sure, version control is commonplace in software development, but outside of that – relatively insular – community it’s far less wide-spread.

I would argue that implementing version control makes sense regardless of the scope of the project or the size of the team. The previously mentioned versioning features in Microsoft Office has allowed me to simply write, trusting that my changes are both automatically saved and revertable. This, in turn, has allowed me to simply write my papers without worrying about saving and manual versioning. Adding cloud storage to the mix allows multiple people to work on the same product, more or less seamlessly.

Doing the same with documentation means you can readily see when a change was made – which fact came in useful when we found that a specific routine had been changed. We could see when it was changed, and who changed it. This let us talk to them and find out why the change was made (because the change was relatively recent).

As I said, none of this is news to the software development community. I do enjoy seeing how it’s slowly spreading beyond that community – including using the exact same platforms. One example of that is how a small community of people on GitHub are maintaining a set of CSV-files used to program ham radios using Chirp.