April 3, 2012

The Problem of Variants in Our Everyday World

Version Control

vacation home

When you study the technology of software version control, you start to see variants everywhere. In this context, variants are closely related, but not identical copies of an object. Computers have accelerated this problem because they are so darn good at making copies of things. Every time you attach a document to an email or “Save As…” you create a copy.  And once you make changes to those copies, you’ve set the stage for trouble between the resulting variant copies. (When we talk about consecutive, incremental variants, we often use the more commonly seen term, versions.)

A Real World Example

I was recently discussing with my mother-in-law issues around scheduling a vacation rental house managed by the extended family. It’s a short term rental that’s also used by the family members throughout the year, so it’s important for several different families to coordinate who is there when and when it’s being rented out. We used to handle this issue by having each family maintain their own copy (i.e., variant) of the schedule, which was kept up to date with sporadic emails, phone calls and discussions. A software professional will easily see this as a data replication nightmare full of potential for conflict!

One easy solution, which works well in simple situations like this, is to get rid of the copies, thus extinguishing the variant problem. Turns out, there are websites that specialize in hosting and planning just this sort of thing.  Of course, a shared Google calendar or document could also work. One single document of reference puts everyone, literally, on the same page.  

Unfortunately, you’re still left with the manual task of assembling that initial version from all the copies from each family. It’s not at all unlikely that even a single family has several variants of the schedule.  

How Version Management Could Solve the Problem

In the realm of software, version management might refer to the process of combining the copies as merging variant copies of source code files. As part of this process, you might also want to know where certain numbers in the new, master copy originally came from. In software we call this a “blame” command, which identifies the author of any line of code in a file. Version management is a virtual “man behind the curtain” that tracks the relationships between changes and makes it possible to understand these types of things.

Let’s take this a step further and see where else there might be additional parallels to software source code management. For example, individuals scheduling the vacation house might want to submit a proposed plan for review before making an official edit to the master document. That way, only after all the stakeholders sign off is the plan eligible for inclusion. This reminds me of the code review step before submitting a source code change to a mainline or master code repository. It’s also easy to imagine how those specialized event collaboration web sites I mentioned earlier might (re)discover the need for “review before commit.”

The “single document” approach works pretty well for relatively small groups of collaborators, and it’s certainly a big improvement over the prior method. However, if the document in question required frequent updates, or had more concurrent authors, contention problems might arise. I’ll make that the topic of a future post.

Thinking of the world in terms of version management, which includes variant copies, reconciliation of multiple variants, and tracking relationships between changes, makes it clear that versioning challenges are all around us. Since the ability to version in highly collaborative environments is the technical core supporting Perforce’s Version Everything mission, I’m always on the lookout for new ways to apply our expertise to a wide set of problems—even my mother-in-law’s house-sharing schedule!

Where do you see “the problem of variants” in your life outside software?