How do you explain the importance of using a [distributed] version control system to someone who's not in the CS field? [closed]

Question

A good example of someone who fits that description might be a project manager.

I was asked by my boss the other day, "what this Github thing is and why it's important?" He has some proprietary projects so he would need private hosting and I found myself struggling to explain beyond the usual: VCSs make collaboration trivial, provide a history and "backup" of all your data, and allow you to record atomic changes in a code base. In my mind I was thinking, "it's almost as if you have to use a DRVS to really understand how beneficial it is".

I ended up pointing him to BitBucket because they give you unlimited private repositories (I even had to explain what a repository was).

Does anyone have ay really good concrete examples of how a VCS has saved their ass or made life easier, etc -- basically, how would you sell a DVSC to someone who's not unfamiliar with programming, but not a programmer by profession?

Answer 1

Version control is great for (at least) three four things: backup, sharing code between developers, finding+fixing bugs and progress tracking.

1. Backup. If nothing else, it's backup on steroids. You have the entire development history, each commit is a snapshot of your entire code with an id (revision number), a description, timestamp, user info. And it's simple to compare files between revisions. If nothing else, it's faster than a simple backup (only file changes are sent and stored), and contains much more useful metadata. Why reinvent this?

2. Sharing code between developers. If you have at least two developers working on the same product simultaneously, I don't see any other way to reliably and consistently share code changes and merge them. Sending zips by mail?

3. Finding and fixing bugs. When your customers report a bug for a specific product version, you can quickly get the actual source snapshot in order to reproduce and fix it. It's hard to reproduce bugs if your source is different from customer's. Do you ask them to send the executable so that you can disassemble it? Furthermore, if you have problem identifying the cause of a bug, you can use VCS to pinpoint the exact revision where it was introduced.

4. Progress tracking. When you commit your work in snapshots, it allows you (and your manager) to track progress on feature implementations and status of open bugs. VC systems are also easily integrated with tracking systems and continuous integration systems. It's close to impossible to keep a level of quality for anything else other than a hobby project, unless you have a VCS.

Once you have all agreed that no software development should ever be done outside a VCS (I wouldn't miss it even for a hobby project), then you can discuss features of a (slightly more complicated) DVCS (the following part blatantly copied from Wikipedia):

• Each user has its own local copy of the repository (and effectively, a backup copy)
• Allows users to work productively even when not connected to a network
• Makes most operations much faster since no network is involved
• Allows participation in projects without requiring permissions from project authorities
• Allows private work, so users can use their revision control system even for early drafts they do not want to publish
• Avoids relying on a single physical machine as a single point of failure

Answer 2

"Have you ever found the 'undo' button useful? Oh, so you agree we should use a version control then?"

When I started using version control the main feature I was interested in was the ability to 'undo' my mistakes and go back to a previous version. Everyone can appreciate an undo button. Granted version control can do a lot more.

Answer 3

Start with the basics:

Firstly a VCS protects developers from themselves and from each other - if it served no other purpose than to allow two or more developers to work on the same codebase relatively safely it would be of huge value (and I have been in a team where the previous days work has been overwritten by a bit of careless copying).

Secondly it provides an audit trail - a history - you can go back and see who changed what and when and you can go back and retrieve code that you deleted because it was no longer needed or appropriate when it turns out that it will be needed after all.

Thirdly it gives you a reference point - the definitive source is the committed code (in the real world its a bit more complicated, especially with DVCS, but for the sake of this discussion its close enough). If you have the repository properly backed up you should then have company's asset protected.

Those three things should be "it" for selling VCS - if a manager can't see sufficient value in the above its time to find another manager.

Once you've sold VCS (which are, after all, only of use to development teams where the number of devs is greater than zero) then the question of why DVCS over, say, SVN or TFS and the further question of whether to work in house or to use a hosted service such as Kiln or Bitbucket or Github (which does private if you pay) is rather deeper and more context dependent.

Answer 4

VCSs

Just explain the concept of backups. Backups let you see what you had been working on at a given moment in time. Tell how before VCSs programmers used to copy their entire projects compulsively, generally to save each good and stable release they had, so when things went bad they had a good point of reference of when things worked, compare them with the latest stuff and see where they or someone else messed up and fix it easier by just looking at the differences instead of the whole two backups of the project.

In summary: VCSs let you save backups of your work and give you the ability of seeing only the differences between backups.

DVCSs

As for distributed version control, explain how typical version control used to need a server and an internet connection and that everybody got tired of that because it was slower and everybody worked on a single backup, if one messed up it messed the project for everybody, so with distributed version control everybody can work on their own backup in their machine without an internet connection, and everybody is happy because no one messes with their backup while they work and they can worry about sharing their work later when they are done.

Another good one is that unlike a centralized VCS where there is only one backup, if the machine with the backup catches fire there are still other complete backups to go around (at least one for each developer).

In summary: DVCSs let you work in your own backup without everybody having to be crammed in a single server bothering each other, and let you worry about others changes after your are finished with your stuff. Also, nothing happens if the main repository machine catches fire.

Answer 5

I work mostly with engineers (not developers per se, but they do write code)

The main point, when I explain to them about version control, is the possibility of undoing and managing your code/documentation/whatever and simplifying collaboration with other developers/writers/etc...

That's a good selling point - and was the main reason for me to use a VCS for all my work, also the other advantages: having a history, a repo that can be easily backed up...

Most of them like the idea and find it quite useful, adopting it for their projects (specially if they involves collaboration with other engineers).

Answer 6

When trying to convince anyone of anything, you always need to try to come at it from their point of view.

Your project manager has a simple goal - completing projects on time and on budget.

If you aren't currently using version control, then your development team is solving the problems that version control solves by hand. All of those problems have been well enumerated by other answers, so I won't get into them here.

What you need to do is explain to your project manager that the team is spending X number of hours every week manually solving the problems that GIT could solve automatically, or in, say, 0.1 * X number of developer hours.

Don't approach it using reasons GIT will make your life easier or the lives of your fellow developers easier, approach it from the perspective that GIT will ship software faster and cheaper.

Answer 7

I like @Buttons840's description of it as an undo button for the code base. It might also help to compare it to a (less frustrating) version of Word or InDesign's "Track Changes" feature. In my experience, it definitely reduces the need for one person to go around telling others not to touch files X, Y, and Z for the next few hours, which is handy for getting things done.

I've also found the fine-grained version info incredibly useful for fixing/working around bugs. I stash the SVN version number (via the $Id property) in nearly every data file I generate. That way, if (when?) a bug is found, it's trivial to identify files with potential problems and regenerate them or have other code compensate for the bug.

Answer 8

If you don't use version control, how do you know how to rebuild your production environment?

1 Different people (testers, developers) will look for the same information in different places

leading to DUPLICATE DATA that gets out of sync.
Version control is the easiest way to eliminate duplicate data.

2 If you do use version control, it is easy to ensure the production environment matches what is in the version control.

This makes it easy to detect whether a problem was due to a bad build (prod does not match version control), or a design or coding bug (prod does match version control).

Version control makes it easy to assign a release number to each test environment and you would naturally expect production to have a lower release number than test or development, and test to have a lower release number than development. If this were not the case, some part of the code has not been properly tested..

Answer 9

Also if you release software the following feature of a VCS is rather essential: Assume your customer finds a bug. The current development of the software is probably in a very different state than the version which the customer has. Maybe the bug is fixed in now, maybe it is not, but in any case the current software is not in a state that you can just ship it to the customer.

A VCS makes it trivial to go back to the version that was shipped to the customer, fix the bug he was requesting, build it and ship him a revised version. All this without disturbing current development, without having to ship him a version with unfinished/unstable features or additional bugs introduced due to the new unfinished development.

In addition a VCS makes it easy for you to port this fix back into the new development branch if the bug is still present there too.

By strong discipline you can probably manage this without a VCS for a very small team, but using one will save you time and in the end money. Most likely it will also help you keep your customers.

Answer 10

If your company has more than two people, then you probably have a word document or an excel document lying somewhere that's edited by multiple persons. And sometimes those persons make local copies, to take on a business trip etc. Or the document gets sent around by email after each change.

If you have such a file, then either some people's modifications have been lost in the past, or will be lost in the future. Or people think they've lost changes, but can't prove it. Or they'd like to see who made what change when and why. That's exactly the problem a VCS solves.

Answer 11

When choosing open source software/libraries, having DVCS repository is definitely an advantage in the selection criteria.

1) We can clone the whole repository, don't need to worry about the project or its website is dead.

2) People are more willing to submit bug fix via pull request, result in faster bug fix for urgent issues.