In the past I have worked with designers, BAs and project managers, all who regularly produce project artifacts, yet very really do they understand the concept of versioning. When I try to explain it to them (even in its most simple form of multiple differently named files) they seem to have some kind of mental block. Why do you think this is?

  • 1
    I would have explained a problem which could have solved with the help of Versioning and then would have explained what versioning is all about. you did the same and yet they do not understand?
    – Gopi
    Commented Sep 20, 2010 at 10:31
  • Yes, it is as if they fundamentally do not understand the problem space.
    – Andrew Cox
    Commented Sep 20, 2010 at 10:43
  • 32
    To be fair, lots of programmers don't understand versioning either. Heh, in fact - lots of programmers don't understand programming. Commented Sep 20, 2010 at 10:45
  • Just wear a baby-blue suit and wide tie and rickroll them back to the '70s... Commented Sep 20, 2010 at 17:07

10 Answers 10


This is because the human has difficulties projecting himself in time.

Use the time machine analogy. Your life is versionned. Every day you have a new version of your life: new things and lost things. Hopefully more assets, less debts,... but more fat, less hairs, ... hopefully more knowledge, less doubts, ....

Then you will have to explain branching ;) And there you hope they are fans of Fringe ;)

  • 2
    Hm, nice analogy. I like to rollback to the 24-year old version. Commented Sep 20, 2010 at 11:10
  • I wish I could too for few bad decisions, but did you see the Butterfly Effect ? ;)
    – user2567
    Commented Sep 20, 2010 at 11:12
  • 1
    @Gamecat or at least I'd like to have my 24-year-old body back. I actually prefer my 55 year-old-brain.
    – HLGEM
    Commented Sep 20, 2010 at 15:20
  • 5
    @HLGEM - I like my brain. Brand new, never been used ;-)
    – Rook
    Commented Nov 15, 2010 at 2:05
  • Branching would be the "grandfather paradox" actually happening, I suppose.
    – user131
    Commented Dec 2, 2010 at 11:31

You can use the book analogy.

When you write a book, you first write a draft version. Then you read it, make some changes and reread it. Until you give it to somebody else to read. And of course they have remarks too.

Each change makes a new version. And although you normally use the latest version, sometimes, you regret a change and want to rollback. Possibly the whole book, possibly a single chapter. Versioning gives you this opportunity.

Then the subject of branching.

The book is almost finished, and it needs to be translated into French. So you make a copy of the book and send it to the translator. In the meantime, you make some changes to the original book. Some of them are added to the French translation and others never make it there.

  • 2
    Sounds to me like you are discussing revisison control rather than versioning.
    – danio
    Commented Sep 20, 2010 at 11:43
  • 2
    Seems Gamecat has difficult to understand versioning :-)
    – Maniero
    Commented Sep 20, 2010 at 12:28

Because, in the non-programming world, to change a competed product is very hard. Intentional changes, which are thought through, are not easy—take buildings, for example. And once the changes are made, it's hard to "revert" to previous version.

Contrary to that, changing software is very easy (easier than even other media products; say, a movie) , and "checkout an older version" is a common task in the software world.

Thus, the notion of versioning contradicts out everyday experience, which usually confirms that only one, current version of a thing exists (for software it's not true). That's why it's hard.


In my experience they catch on pretty quickly.

Version 1.0 - We sell for money.

Version 1.1 - Small enhancements for some customers: we sell for a smaller amount of money.

Version 2.0 - Big improvements. We sell for lots of money.

Version 2.1 - Small enhancements for some customers: we se... "Wait a minute" says PM/BA "Rename that to 2.5 and we'll charge 5x as much". No amount of discussion from engineering will convince them otherwise.

Version 2.2 3.0 etc...


You mention that even simple document versioning is giving people difficulties, so maybe you're not explaining it well, or your team are not that bright.

Our developers use git on the commandline for versioning, and once they're up the learning curve, they all cope fine with it. I haven't bothered trying to explain git to non-technical staff because with them there is much less direct collaboration on individual documents - for this stuff we use DropBox, and I've not seen anyone struggle yet.


They need to be aware of various 'doomsday' scenarios. Computer, server, hard drive, whatever, breaks, isn't it great to have a backup? If you can't get them to agree on this concept, you can't move on.

Now, what if they were asked to make a presentation, but on the third page, the client would like to see it with and without the graph. What would you do? Make a second copy with the changes. If they told you they didn't want the graph, would you throw away the 'version' with the graph? Probably not because you never know. If you can't get them to agree on this concept, you can't move on.

Have you ever sent a file for review only to have the person change it? Did you keep your version? Did you have to give the file you sent them a different name because you know when they make changes it is too difficult to tell the difference or save them in the same folder? And aren't these names getting long? If you can't get them to agree on this concept, you can't move on.

Wouldn't it be nice if we has something that would just keep track of all of this for us? No more sending email attachments. No more wondering which one did the Boss make that change on, but I made another change and now we can't get them together. No more long file names trying to explain which 'version' we are on. If you can't get them to agree on this concept, you'll just havce to move on.


I've found that engineers (elec/mech etc) don't start out understanding configuration management, but grow into it ( or drive everyone crazy.)

Software developers might understand versioning.

Non-technical people in general understand nothing from this space. It's technical.

It's part of engineering discipline that they've never had to learn.

An they can choose not to. So plenty of them will.

The only solution is to work somewhere that has management support for a disciplined process. CMMI level 2 compliance is 400% more productive in time and money but people avoid it.


Do you mean versioning or branching/merging?

I think it is pretty straightforward to understand versioning. "We saved the version from Tuesday. Then we did more work. Now it is Wednesday. We can go back to Tuesday's version."

Branching and merging is much harder to explain. "Well, Bob made changes in 1.1 that conflicted with Alice's view of 1.1 and submitted first, so 1.2 has Bob's changes, but 1.3 has Alice's changes too except some of Bob's got integrated later, so..."

  • I mean even simple document versioning and why it is a very good idea.
    – Andrew Cox
    Commented Sep 20, 2010 at 14:26
  • Wow. Then I'm not sure--perhaps simply because it has not been given a motivating example. Commented Sep 20, 2010 at 15:50
  • Maybe they don't care when changes were made to the document and by whom. Until you can show them a situation where versions would have helped they will just see it as make-work.
    – danio
    Commented Sep 21, 2010 at 8:16
  • Perhaps a legal analogy, then. "And here is the version after the opposition's lawyers got to it. Do you really just want to accept it, or would you prefer to be able to compare it to 'our' version?" Commented Sep 21, 2010 at 12:53
  • Funny, Bob and Alice seem to be as canonical to versioning as Foo and Bar are to code :)
    – Benjol
    Commented Dec 2, 2010 at 5:43

Well, Alice writes a blah. Then Bob gets the blah and makes some edits, and Carol gets the blah and makes some edits. These are versions. Then Dan comes in and tells Alice to make a bunch of changes. This is another version. The next day, Dan comes back and says that everything he said yesterday was a lie, and that management wants Carols version of the blah from Tuesday. Having Carols version and being able to find it easily is called version control.


My guess is that most people have a number of things to care about, so versioning doesn't make it to the top of their list. It's like insurance, the payback is of low probability and it's not free.

For the project artifacts that you outline, if there is only one person involved (e.g. a BA's document describing a calculation), they may quite reasonably assess the payback of keeping old versions to be zero.

Requiring more careful versioning of these kinds of things may introduce a hostile element into a project's atmosphere, as the reasons for doing it may be kind of adversarial, i.e. people are expecting to have arguments about old vs. new versions, so they want the old versions to be available as proof.

Not the answer you're looking for? Browse other questions tagged or ask your own question.