One of my clients recently overhauled their talent pool. Their staff went from two freelancers with very general development skills to one generalist (me), two php developers, and a CSS/HTML developer. System administration was understandably not in the three new developers' bags of tricks, and so they needed to be given development environments. As the only remaining person with system chops (and what mediocre chops they are), it fell to me to set these up. The project manager and I decided to set up completely isolated instances of the site and database, all hooked together by our subversion system.

Setup took longer than expected. Between minor issues at the host, incompatability between our code and library versions on the new server, and inevitable communications delays, we lost the better part of the week to our setup. This left several of the clients' staff wondering at why such elaborate preparations were necessary. Why couldn't all the developers just work out of a single environment and database?

This confusion left me at a bit of a loss. I remain confident that we took the right steps in getting our new talent up and running on the project, but I had no idea how to communicate the need to a non-technical individual. Most analogies I worked through fell apart in short order. The building-a-house analogy? Doesn't work - you generally don't have one contractor building a roof while the other works on the foundation. The writing-a-contract analogy? No parallellism to reference.

Finally, I started picking apart some variations on the writing-a-story analogy and came up with one that seems to fit. Let's assume several authors decided to team up and write a character-driven, multi-chapter story. Each author would write one chapter that would feature one main character, and that author would be the authority on that character. However, all the characters will by necessity interact at various points during the story.

When writing begins, each author can work effectively in isolation within his or her own chapter. The character develops, and encounters with the other characters are documented. As these interactions unfold, however, they may begin to start interfering with other parts of the story. What if in Chapter 1, Jonny said "Where will we go next?", while in Chapter 3's telling of the same encounter, he says "Let's go to the cave!"? Johnny's author would need to go into someone else's chapter and fix the quotation.

Now you're faced with the prospect of more than one person editing the same document at the same time. Most people can understand that significant issues can occur here - for instance, if two authors are editing the same chapter at the same time, the chapter will ultimatley contain only the changes of whoever saves last. What you need is a mechanism by which each author can edit a chapter and have their changes merged together seamlessly.

That's where version control comes in. Version control takes the different parts of the story and gives the authors the freedom to make changes wherever necessary without impacting one another's work. When you extrapolate the analogy into real development terms, its usefulness becomes amplified by the fact that it enables editing by anyone, anywhere with an internet connection.

There's certainly some gaps in this description, but for the most part I think it holds up. If nothing else, it serves as an interesting intellectual exercise.