Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

This question already has an answer here:

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 mulitple differently named files) they seem to have some kind of mental block. Why do you think this is?

share|improve this question

marked as duplicate by durron597, MichaelT, GlenH7, Snowman, Dan Pichelman Jul 13 at 18:27

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

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? – Tech Jerk Sep 20 '10 at 10:31
Yes, it is as if they fundamentally do not understand the problem space. – Andrew Cox Sep 20 '10 at 10:43
To be fair, lots of programmers don't understand versioning either. Heh, in fact - lots of programmers don't understand programming. – Jaco Pretorius Sep 20 '10 at 10:45
Just wear a baby-blue suit and wide tie and rickroll them back to the '70s... – Talvi Watia Sep 20 '10 at 17:07

10 Answers 10

up vote 13 down vote accepted

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 ;)

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

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.

share|improve this answer

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.

share|improve this answer
Sounds to me like you are discussing revisison control rather than versioning. – danio Sep 20 '10 at 11:43
Seems Gamecat has difficult to understand versioning :-) – bigown Sep 20 '10 at 12:28

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...

share|improve this answer

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..."

share|improve this answer
I mean even simple document versioning and why it is a very good idea. – Andrew Cox Sep 20 '10 at 14:26
Wow. Then I'm not sure--perhaps simply because it has not been given a motivating example. – Alex Feinman Sep 20 '10 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 Sep 21 '10 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?" – Alex Feinman Sep 21 '10 at 12:53
Funny, Bob and Alice seem to be as canonical to versioning as Foo and Bar are to code :) – Benjol Dec 2 '10 at 5:43

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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