Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming

Ask Slashdot: Explaining Version Control To Non-Technical People? 383

New submitter billius writes "I was recently hired (along with another guy) as a web developer at a large university. Our job is to build tools to support the social science researchers on our team. When I got here the codebase was an unholy mess: the formatting was terrible, there were .bak files scattered everywhere and there was no version control system in place. We quickly went to work cleaning things up and implementing new features. My boss was so pleased with our work that she took us out to lunch. During lunch, she asked us if there were any additional tools we needed to do our job more efficiently. We both told her that version control was an invaluable tool for any kind of software development, but had a difficult time describing to her what exactly version control was. I attempted to explain that it created a log of all the changes made to the code and allowed us to make sure that multiple developers working on the same project would not step on each other's toes. I don't think we really got through to her and a few weeks passed with us hearing nothing. Today we were asked by another supervisor if we needed any additional tools and we went through the same spiel about version control. She suggested that we try to write up a brief description of what we wanted and how much it would cost, but I'm drawing a blank an how exactly to describe version control to a person who isn't very technical, let alone a developer. Does anyone out there have any tips on how to sell version control to management?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Explaining Version Control To Non-Technical People?

Comments Filter:
  • by eldavojohn ( 898314 ) * <eldavojohn@noSpAM.gmail.com> on Tuesday September 25, 2012 @09:04PM (#41458501) Journal

    She suggested that we try to write up a brief description of what we wanted and how much it would cost ...

    I don't understand why this story is tagged with git and svn then asks how much it will cost. Check out Gitstack [gitstack.com], roll your own git on Linux [moocode.com], or any of a million ways to do svn or cvs ... I mean, every version control system I've used in the past ten years has been free. I mean, if you're talking about ... what, SourceSafe? Is there some crappy IBM like ClearCase thing? You think you need to pay for an online service? I don't think you need to move this off your own personal servers unless you want it open sourced. What features are the tagged version control systems missing that you need to request funds for?

    Here's how I explain version control to non-techies: "Remember that time you had to work on a group project and you started writing a word document in MS Office and then you passed it out to the group while you still worked on it and then you got four more versions back with corrections and updates and you just started cursing out your computer? Yeah. Believe it or not, they fixed that problem for software a very long time ago and it's dirt cheap. In fact, if developers follow simple rules, those versioning nightmares you had with your group's powerpoint and other Microsoft files never happens."

    People have dealt with this problem in other realms for a long time so you just need to find something to relate it to that they've experienced and it'll start clicking much faster. Failing that, wikipedia has visuals [wikimedia.org].

    • by jabberwock ( 10206 ) on Tuesday September 25, 2012 @09:15PM (#41458613) Homepage
      This question only needed one answer, and the first post had it.

      I wonder if that has ever happened here before?

      • From TFA:

        We both told her that version control was an invaluable tool for any kind of software development, but had a difficult time describing to her what exactly version control was

        I attempted to explain that it created a log of all the changes made to the code and allowed us to make sure that multiple developers working on the same project would not step on each other's toes

        Look, geeks evolve too.

        In the olden days, geeks were geeks, and geeks didn't have to say non-geeky things to non-geeks.

        Nowadays, it's different. We have to explain very geeky things to non-geeks and you just can't load up all the jargons and tell it to the non-geeks. They will go bonkers !!

        Nowadays we geeks have evolved into geeks who can speak every-day-language using non-geeky-examples, ie., analogies

        In the case like TFA, the submitter could have use the example of

        • by Chris Mattern ( 191822 ) on Wednesday September 26, 2012 @05:59AM (#41461659)

          If the recipe calls for 3 eggs, two scrambled and one sunny side up, and cook A already done one egg scrambled, he better let cook B and cook C know what he has accomplished. That's where version control comes in.

          Aaaaand you've now convinced your manager that version control has something to do with cooking eggs.

      • by Jane Q. Public ( 1010737 ) on Wednesday September 26, 2012 @01:47AM (#41460451)

        "This question only needed one answer, and the first post had it.
        I wonder if that has ever happened here before?"

        Damned straight. I would not even have spoken to my supervisor about it. I would have installed Git and gone with it.

        If (for some Gridawful unforeseen reason) the supervisor had a problem with it later, I would go over supervisor's head and ask the next boss up why supervisor doesn't know how to do her job.

        Period. End.

    • by CastrTroy ( 595695 ) on Tuesday September 25, 2012 @09:19PM (#41458655)
      The problem is that you can't do a diff between Word documents. Source control and diffing tools work great on source code because it's all just plain text. But for things like Word documents or Powerpoint presentations things get a little more complicated. Sure with a version control service you won't lose any previous versions, but you don't know what changed between versions either. To me this is the major thing missing for MS Office, and I can't believe they haven't done it yet. Sure they have track changes, but you have to remember to turn that on. There's no reason you should have to track changes. You should be able to take two versions of the document and MS Word should be able to tell you what has changed between the two versions. I think that if OpenOffice developed this feature it would be a killer feature that might get people to actually start using it. Because as you pointed out, when you have 4 different versions of the same document from 4 different people, it's nice to be able to figure out which changes those 4 people actually made without going through all 50 pages of the document.
    • by johnkoer ( 163434 ) <<moc.oohay> <ta> <reoknhoj>> on Tuesday September 25, 2012 @09:23PM (#41458717) Homepage Journal

      I mean, every version control system I've used in the past ten years has been free

      Cost is not always measured solely in software costs. You typically need servers to support the software and last time I checked they cost money. Also, employee time is not free for setup of the repository, for training and for documentation of the process.

      I love SVN for version control, but it is never free. It's just less expensive than other software alternatives.

      • It is 2012, and we have things like git and mercurial on these days. If there is no server available, you just put your codebase on version control in place, without having to configure a single file. It just won't work if you don't have 2 or 3x free disk space as your source files take - but in that case you have deeper problems than the ones we are dealing with.

      • I mean, every version control system I've used in the past ten years has been free

        Cost is not always measured solely in software costs. You typically need servers to support the software and last time I checked they cost money. Also, employee time is not free for setup of the repository, for training and for documentation of the process.

        It's at a university - they have servers laying around and "employees" AKA "work-study students" are for all practical purposes free.

      • by Lehk228 ( 705449 ) on Tuesday September 25, 2012 @11:09PM (#41459609) Journal
        Version control has a negative price in most environments, although that negative price is not collected until the first few times it saves your ass.
      • by billius ( 1188143 ) on Wednesday September 26, 2012 @02:25AM (#41460639)
        Hey everyone,

        First of all, thank you so much for all of the responses! I've seen some really good ideas and I appreciate all the input. It seems that I unfortunately wasn't quite clear enough in my initial post. The other developer and I have been trying to get the management to spring for an online service like Github or Kiln. To answer a few frequently asked questions:

        Q: Why don't you just run git/svn/hg on your local machine? A: I am running hg on my local machine currently for version control. While this is much better than no version control at all, it leaves a lot to be desired in terms of collaborating with the other dev and managing deployment.

        Q: Why not run your own server? A: The other dev and I have talked about this, but there are a few problems. First and foremost, it takes time to setup and maintain such a server and the cost of many online services like Github are pretty modest. The other problem is that we're not really in control of the servers and equipment. That's handled by a separate IT group, so we would have to get them involved to make this happen. Then there's the fact that the IT guys at our work mostly deal with Windows servers while we're mostly *nix fans. Neither one of us has setup a Windows box as a VC server before, so I'm really not sure how well-supported that is. What is really boils down to is the fact we could get a month of hosting at Github that would suit our needs for about the cost of an hour of work from on person. Therefore we kinda figured that it might just be easiest/cheapest to go with a service like Github.

        Anyway, thanks again for all the responses!

        • by styrotech ( 136124 ) on Wednesday September 26, 2012 @04:30AM (#41461233)

          So, it sounds like:

          a) You use mercurial,
          b) You want the functionality of github or at least most of githubs functionality,
          c) You need some sort of private repository or repositories,
          d) You might only have a few developers on your team,
          e) You are having trouble convincing your bosses enough for them to pay for something...

          Have you looked at bitbucket.org?

          The free plan gives you unlimited private repositories, and up to 5 collaborators for those private repos. And you can create either hg or git repos. By being free, you presumably don't need to convince your boss to pay.

          And you can get a few extra free users at the moment too:
          http://blog.bitbucket.org/2012/09/18/refer-a-friend-to-bitbucket-for-free-users/ [bitbucket.org]

          Generally I prefer github overall (only slightly though), but they have no free offering with private repos and in general they can be more expensive. I find bitbucket is "good enough".

      • SVN is not only free, it will *make* you money.

        The cost of not having a decent version control system is higher than having one.

    • by amicusNYCL ( 1538833 ) on Tuesday September 25, 2012 @09:27PM (#41458767)

      Another analogy is backup, everyone knows what a backup is. Source control is like a backup that contains every change ever made to every file, who made them and when, and allows you to switch between them to find and fix problems. They might have a hard time understanding merging, but they at least know what a backup is.

      • by Auroch ( 1403671 ) on Tuesday September 25, 2012 @09:32PM (#41458809)
        Agreed. If I had mod points, this is how I'd explain version control to an apple user. I mean, a non-technical user. Besides, everyone likes backups, and playing the "scare" card should get some buy-in on your implementation.
        • by tlhIngan ( 30335 )

          Agreed. If I had mod points, this is how I'd explain version control to an apple user. I mean, a non-technical user. Besides, everyone likes backups, and playing the "scare" card should get some buy-in on your implementation.

          If they're an Apple user, you just say it's a finer-grained version of "Time Machine" or with Lion and Mountain Lion, revisions (the OS auto-saves for you, maintaining previous versions you can cut and paste from at any time).

          Or you can explain it by detailing a typical document product

      • Only if people commit their changes. I can't count how many times I've seen people (and I'm guilty of it too) spending an entire day hacking away getting a feature into a code base, hundreds of lines of code and don't commit it until it is "done". I get that you don't want to check in non-working code because someone will pull it in then bitch at you for it not working. But at the same time it means that whole features are often checked in as one lump, rolling back to 2 hours ago when part of the code stil

    • She suggested that we try to write up a brief description of what we wanted and how much it would cost ...

      I don't understand why this story is tagged with git and svn then asks how much it will cost.

      Amen bother. To Poster: Don't explain how much it will cost. Go get SVN, which is free and simple. GIT is more powerful, but sort of overkill if you are just two people within shouting distance. Don't bother trying to explain it to her, and use her offer to help with tools on a product that you can't get for free.

      • Amen bother. To Poster: Don't explain how much it will cost. Go get SVN, which is free and simple. GIT is more powerful, but sort of overkill if you are just two people within shouting distance.

        iPhone user?

        -AI

    • Or just pay Codesion the damned $50. How cheap are you?

    • I mean, every version control system I've used in the past ten years has been free.

      Sure, but I doubt your time has been free-as-in-beer. When the boss asks "how much will it cost," an honest answer includes an estimate of man-hours to set it up.

      Installing git or svn does not take long, but there may also be time required to designate a server, hold a meeting to debate git vs. svn, etc.

      Put another way, the total cost of free-as-in-beer software is comparable to the hidden costs of commercial software. :-) (

      • by Jeremi ( 14640 )

        When the boss asks "how much will it cost," an honest answer includes an estimate of man-hours to set it up.

        Do we get to deduct the number of man-hours that will be saved after it is set up? Because I think any programming shop would be back in the black after about a week -- or after the first instance of massive code-loss was avoided, whichever comes first.

        • Do we get to deduct the number of man-hours that will be saved after it is set up?

          Yes, but that is the cost of not doing version control. Estimate the costs for both the yes and no states of the decision it then becomes a no brainer for the boss. Even if they don't have a clue what a version control system is, they will understand the concept of insurance.

    • by Anonymous Coward on Tuesday September 25, 2012 @10:16PM (#41459171)

      Cost is *not* the issue. You don't just "put the website under version control" that's a command in a free to download, free to use software package called [ git | svn | cvs ]. Source Control is *not* a tool. It's a technique. You don't need supervisor permission to backup your files, and you don't need supervisor permission to use source control. What you need to do is start using it, and ensure that everyone *else* who contributes uses it, too. That's a policy detail and needs someone to enforce it.

      The selling point of source control is that it is more than just a backup - it allows you to track changes to the site and more importantly *who* made *what* changes and *when* and *why*. Otherwise you don't know if changes are made, who made them, when they made them, or why they were made. One would think that *social scientists* would be able to appreciate knowledge of history without any notion of "cost"!

      • Source Control is *not* a tool. It's a technique

        Quoting the above to draw the attention of mods to the most informative comment in this thread.

    • by cob666 ( 656740 )
      You might want to NOT focus on the 'Version Control' aspect and focus more on 'Source Control'. Centralized repository for all source code, easier to back up, ability to track changes to documents. Mention version control only as a type of 'undo' feature that is always available.
    • by GryMor ( 88799 )

      The only non free (as in beer) source control I'd recommend is Perforce, but really, gitstack or svn will work just fine.

      The cost should be the cost of a server with enough space for the repository and the S3 account for backups. You probably already have a server you can use, and S3 storage is cheap.

    • You can even show them a Word doc doing change control, they solved that for docs too. Computers are absolutely outstanding at this task, they were practically designed to do it. If you're not familiar with it, your boss probably is.

      The difference with development is, it's ABSOLUTELY POSITIVELY CRITICAL. We manage millions of lines of code, and there's no human to figure out what we meant or fill in blanks from careless edits. It allows us to track down the root cause of bugs, and avoid making the same mist

    • There are still fixed costs to maintaining a server even if the software is free. A git or SVN server won't store it's own backups offsite. Our Engineering department still gets charged by our IT department for hosting for wikis, source control, etc, even though the software running on the server is 'free', it doesn't deploy and maintain itself.

  • by Anonymous Coward on Tuesday September 25, 2012 @09:09PM (#41458535)

    You could say it's like Mac OS' Time Machine, where files are backed up and can be pulled up from the past. Then say it's like each user can work on their own copy in time and put the files together in the future.

    Or you could just ask for server space and stick the repo in a central location.

  • First, you should've added a 'Mercurial' tag. :-)

    Explain what it will do for them. For example...

    So, let's say we're working on the website and the code behind it. We push out some new code one day, and a few days later, after we've already started working on a bunch of other stuff, someone reports a bug. One of the form fields isn't validating correctly.

    But, we've been working on that form already. We can't really tell if the bug is still there, or if maybe it was something that was wrong that got moved around. We also can't tell how the bug got there in the first place. That's because we don't know what the old code looked like exactly anymore.

    But, suppose we had a version control system.... Then, when we push new code out to the site, we know exactly which version we push. When someone reports a problem, we can easily go back to that version in a testing environment to find the problem for ourselves and figure out exactly what's causing it. And then, once we've determined the cause, we can analyze the history (because we've been keeping a history of everything we do) to figure out how the problem got there in the first place so we can do better next time.

    There you've explained how it helps you. You no longer need them to understand what it is exactly. You've just explained why it would be good for them to get it for you, and that's all they really care about anyway. They don't want to understand what it is. Understanding stuff like that is why they hired you in the first place.

    • by DJRumpy ( 1345787 ) on Tuesday September 25, 2012 @09:19PM (#41458653)

      Very much this. Trying to give a technical reason to a non-technical person who doesn't understand the benefit is futile. Take a lesson from Apple. They explain technical benefits in a 'what it will do for you' way.

      Give a scenario where the lack of version control does something suitably bad, and then explain what it does when properly implemented.

      One caveat. Keep the benefit a bit more watered down than above. When dealing with management, keep it simple, and meaningful to them, not to you. Talking about validating a form field or whatnot isn't a good way to go about it. Talk about the lost time and productivity, potential impact while troubleshooting and finding root cause, etc.

  • by Anonymous Coward on Tuesday September 25, 2012 @09:14PM (#41458585)

    I will quote from Stack Overflow (http://stackoverflow.com/questions/1408450/why-should-i-use-version-control):

    Have you ever:

            Made a change to code, realised it was a mistake and wanted to go back?
            Lost code or had a backup that was too old?
            Had to maintain multiple versions of a product?
            Wanted to see the difference between two (or more) versions of your code?
            Wanted to prove that a particular change broke or fixed some piece of code?
            Wanted to submit a change (patch) to someone else's code?
            Wanted to see how much work is being done (where/when/who)?
            Wanted to experiment with a new feature without interfering with working code?

    In all these cases a version control systems should make your life easier.

    • by plover ( 150551 ) on Wednesday September 26, 2012 @01:33AM (#41460365) Homepage Journal

      Another link from Stack Overflow (http://stackoverflow.com/questions/1469623/a-few-basic-version-control-questions) was a link to this series of articles on source control by Eric Sink: http://www.ericsink.com/scm/source_control.html [ericsink.com] Chapter 0 includes his list of benefits:

      • It provides a place to store your source code.
      • It provides a historical record of what you have done over time.
      • It can provide a way for developers to work on separate tasks in parallel, merging their efforts later.
      • It can provide a way for developers to work together without getting in each others' way.

      For a completely non-technical manager, a money analogy is probably more appropriate. Remind them that their source code represents the total of investments they've made in developing software. It's the output of thousands (or millions) of hours of very expensive labor. A source code control system is like a bank, keeping their investments safe and organized.

      From there, you can use all of these arguments to point out how expensive it can be to not have a source code control system. It's a single point to back up, making maintenance of all your source code simpler and more manageable. It lets you get back to when something worked, in case someone's made a change that broke stuff. It's an efficient way for developers and projects to share code, to browse the whole library of what you've got. Let them know that it makes people working on a program more efficient, because they're not spending time hunting down where the code is hiding. Let them know that the development tools you already use have the capability to integrate into source management tools (assuming you use Eclipse or Visual Studio) and that they work faster with them. A good source code management system makes things faster, not slower.

      You might give them specific examples of a couple of costly failures that impacted your organization. "Remember that time Joe spent two months working on Project X, and then his PC crashed and his disk drive went bad? Remember when Jane suddenly left and nobody could find the stuff she'd been working on? Those incidents had to have cost us several thousand dollars each in wasted effort redoing all that work. A source code control tool would have prevented them automatically."

      You could remind them that it's a computer program whose entire purpose is to automate the processes that your people are currently managing with manual processes. It can do those tasks far more reliably and much faster than the humans.

      And to dive off the deep end, a complete application lifecycle management system makes it much easier to organize everything about your products. It lets you manage everything by storing it all in the tool, such as requirements or other project documentation, along with the source code. You can manage the projects in the tool, by assigning work items in it, collecting and managing bug reports, creating tests, managing product feature backlogs, etc. An ALM tool can make the project visible to everyone involved by presenting project status on a web page. But given that your manager doesn't yet understand the value of such an ordinary and foundational tool as a source code management system, you'd no doubt scare them off by throwing out an ambitious plan to change a lot of stuff. But it wouldn't hurt you to consider features like those as potential next steps of improving your software engineering practices.

  • Tell her that it's like a car. You have different models every year, but you want to keep the old ones as a reference so that you can check out the old ones if the new ones have issues.
  • It is simple-- Word's track changes on steroids. How much more than that do you really need to explain-- beyond working on a single "document," it works across all "documents" at the same time, but without mangling the report or needing to "accept changes" for each line of code.

  • by davidwr ( 791652 ) on Tuesday September 25, 2012 @09:14PM (#41458595) Homepage Journal

    Get his attention with this:

    "Would you run a business without a ledger?

    We've been running our software development like that and it's high time we started doing it right."

    Now that you have his attention, you can sell him on the particular version-control-system you want and, if necessary, explain the other good things a VCS can do, like provide legal accountability of which employee checked in what, forking off maintenance releases, and more.

    • by clintp ( 5169 ) on Tuesday September 25, 2012 @10:12PM (#41459153)

      Mod the parent up, this is the first non-techie analogy that makes sense to anyone with any accounting or business background.

      The "ledger" idea is the elevator speech you can give to the pencil-pushers. It's one thing to know what the bottom line on a balance sheet is, it's another thing to know how the numbers got there. Multiple sources of changes (Payables, Receivables, Sales, Petty Cash, etc...), in multiple directions (debits/credits), in multiple categories (Assets, Liabilities, Equity) . You'd be foolish to run a business without a general ledger. Source control is the ledger for the software.

    • by PPH ( 736903 )
      Read the summary: The OP is working for the social science department of a university. So the answer to the question, "Would you run a business without a ledger?" might very well be, "What's a ledger?"
  • by iiii ( 541004 ) on Tuesday September 25, 2012 @09:14PM (#41458599) Homepage

    Why are you explaining and asking permission to use a tool? Download git, install it, use it, done. Standard practice, free, so what's the issue? Just do it. The management doesn't want to see how the sausage is made.

    Also, there is a "manage your management" issue here. When the bosses ask if you need anything, you need to provide answers that they understand and can accomplish. Asking for something they don't understand and don't know how to get for you leads to them feeling stupid and ineffective. Line up your own tools without bothering them. When they ask what you need be ready with something that they can easily accomplish, like stocking the fridge with Mt. Dew.

    • Agreed. General rule for life - it's always easier to apologize afterwards than ask permission beforehand.
    • by rknop ( 240417 )

      Exactly -- just do it. Download, install. Start doing "releases" of the tools for the social science researchers to use-- they can download tarballs (or whatever) and install them. You can also write a quick instruction web page for "how to get the latest version" that tells them how to svn (or hg or whatever) checkout the source, just in case anybody cares. But you'll have the version control for what you need. Only demand that the others learn it if they're banging on the code themselves.

      Eventually,

    • This. You should ask for extra RAM to run your 64 bit server properly AND a stocked fridge. Make sure you've got a decent switch in place for the extra traffic VCS will generate. Nothing worse than everyone trying to check out the latest version on a slow network attached to a memory starved server.

      • Nothing worse than everyone trying to check out the latest version on a slow network attached to a memory starved server.

        Git is another solution to this problem. Cloning the repository is harder on the network because you're downloading a complete revision history (though represented in a very compact way) but requires virtually no CPU or RAM on the server, and once you've got your clone all of your subsequent work is very low-impact on the server in all respects: network, RAM, CPU.

  • "It's like massively-multiplayer undo!"

  • by indymike ( 1604847 ) on Tuesday September 25, 2012 @09:19PM (#41458667) Homepage
    Version Control for code is exactly like accounting software for money. Without accounting, your business would fail as it becomes more complex. Eventually, without version control, the process of building software will fail as development becomes more complex.
    • by Auroch ( 1403671 )

      Version Control for code is exactly like accounting software for money. Without accounting, your business would fail as it becomes more complex. Eventually, without version control, the process of building software will fail as development becomes more complex.

      This is an awesome answer.

      Just saying.

  • by pclminion ( 145572 ) on Tuesday September 25, 2012 @09:20PM (#41458673)

    As a blatantly non-technical person, your manager neither needs to know, nor cares, why a developer would want version control. You were hired to develop software, this is part of developing software. If it was a matter of cost, you would need to discuss it, but since there are good free source control systems available that don't require a dedicated server, just pick one and start using it.

    Do you also need to justify your use of a particular text editor or IDE? If management is technical I can see how they'd want input on these decisions (even in that case maybe unwanted), but for somebody non-technical you are just producing your own confusing mess by bringing it up in the first place.

    Your job is to develop, go do that.

  • She suggested that we try to write up a brief description of what we wanted and how much it would cost, but I'm drawing a blank an how exactly to describe version control to a person who isn't very technical, let alone a developer. Does anyone out there have any tips on how to sell version control to management?"

    You don't have to describe the workings of an internal combustion engine to explain how a car is useful.

    When you have multiple people working on the same thing, you need to be able to track what happened when, so that you know what code a bug was reported in. You also need to "lock" portions of the code so that only one person is working on it at a time. List all such benefits, and try to put a price on them. Be reasonable though, as most of them are "fixed" by other means, and you don't want to sell a

  • Explain that it's a morale issue, makes developers feel they're working on a solid foundation.

  • by Trip6 ( 1184883 ) on Tuesday September 25, 2012 @09:26PM (#41458765)
    She thought enough of your work to take you to lunch? I think you have to declare that. I've been doing version control for years and never even got a Twinkie.
  • You just put the minus signs and the decimal points in different places.
    Congratulations Jones, the board loved your presentation. We've just put you in charge of accounting.
  • I usually explain version control as working just like a library with a small twist. Imagine that this library holds paper notebooks that are partially used. You can go to the library, checkout a notebook, and write and erase parts of it while it is in your possession. Just like a library, if you have the original notebook, no one else can check it out -- you have exclusive rights to the notebook.

    There is a bit of a twist that you can think of as working like an attentive librarian: every time the notebo

  • Non-technical people don't care how version control works or what it does at a low level, and they shouldn't have to. I would explain what type of problems it helps solve, with examples.

    Programmers have to make changes to programs to try and improve them. There are several parts of that job that are made easier with version control software. Some examples are:

    • Sometimes those changes don't work as expected. They might break a program that worked before the change. Version control software lets you easil
  • "During lunch, she asked us if there were any additional tools we needed to do our job more efficiently"

    Don't ask, what's going on here is that neither of them will take responsibility of implementing changes. You may well wonder the managerial polotics that results in why you have to report to a non-technical administrator. Just install the thing and go ahead and start using it.
  • by mothlos ( 832302 ) on Tuesday September 25, 2012 @10:04PM (#41459087)

    Metaphor can be useful, but it can also cause problems. Here is a shot at a simple explanation without metaphor.

    A version control system maintains a log of all changes that are made to the source code of a piece of software. When a problem arises in a piece of software, the version control system can help find out what code was changed, when it was changed, and who changed it. Without this information, tracking down the piece of code causing the new bug can take a lot longer. This log can also be used to undo changes which prove to be problematic.

    Explaining how version control helps developers recognize conflicting commits is a specific example and likely lost on lay folk without quite a lot of explaining.

  • Explain that it is three-fold:

    1) The first is a record of all prototypes and changes along the way.

    2) A back up repository that keeps a copy

    3) Facilitates multiple people working on the same item so that everyone receives the changes.

    How to conceptualize it, express that it's like designing a brochure. You create a rough draft, it's send to your boss for review. She requests changes. So you create a revised copy with her changes. It then is sent off to the department head, and the project head. Both make

  • Version Control is like a very long cat. You pull the latest stable version off in New York, meanwhile an unstable beta is mewing in Los Angeles. Version Control is the same, only there is no cat.
  • You tell them that Apple, Facebook, Google, and Microsoft all use it in some form, and that it's necessary for any form of development. They go "Wow, I didn't know! Where do I sign?"
  • Use a technical document in a library as an example. When changes are made in a piece of machinery those changes need to be reflected in the technical documents that show how a given piece of machinery works. So the manufacturer sends out "changes" in the form of a few pages reflecting the changes, and instructions as to which pages to replace.

    The old pages are thrown away, and the new pages and the title pages now reflect that the document is now version 1.1 instead of 1.0. As this continues to happen over

  • Turnkey Linux and Amazon S3 - the download's free and I spend a couple of dollars a month to store backups. All you need is a machine :)
  • You could get one of tens presentations on what it does, point them to the wikipedia article on version control -- but I see all of that as orthogonal to actually using it.

    Just _do_ use git or mercurial on the project - you should already be doing it, and you know that. Btw, those 2 systems are light years ahead anything proprietary V.C. tools have to offer nowadays - not ot mention the complete desburocratization on initally versioning a code base to start with: no need to setup a server, no need to a comp

  • Comment removed based on user account deletion
  • Blame; being able to know who inserted racial slurs into your product is useful for knowing who to fire.

  • Explain to them that version control is the cornerstone of practically all modern software development best practices, whether they be agile or waterfall oriented. It's open and shut. You can't do best coding practices without version control. Period. The reason is that version control is fundamental to collaboration. Without it collaboration is awkward, time consuming and error prone.

    If the project is small with only a single developer, collaboration includes handing off responsibility for the system to t

  • Every version control system which is free is better than every control system which isn't. NOT BECAUSE it's free, or because it's open source. But because it is. There is plenty of examples of bad open source projects. Version control just happens to be better implemented in the open source projects. Some will, undoubtedly argue it is because of the the philosophy itself, I will reserve the judgement of the philosophy for myself (in this case) and let everyone be their own judge of the open source phil
  • Code break more often, if not version controlled!

    Or... you know... it remembers every change you ever made to the code ever since you stuck it in version control, so that if you screw something up six months ago, you can see where that problem was introduced and remove it without affecting any other changes. It is absolutely necessary as your team expands beyond more than just a couple of people, and even has benefits with smaller teams. Personally, I use git for my personal projects, and host most of tha

  • I like Michael R. Head's description of VC as "Saving All Your Work Forever":
    http://www.cs.binghamton.edu/~mike/seminars/cvs-svn-bzr-bucs-seminar-2007.pdf [binghamton.edu] .

  • just say that we use version control to do what we want:

    - using Git/Mercurial is like walking naked on the beach
    - using svn is walking naked at home
    - using Clear Case is going through airport scanning and being detained 30 min for having a nail cutter, followed by anal examination
    - using Visual Source Safe is terrorism. It's lie having your balls hit repeatedly, by something like the door of a submarine.

  • For a small project, any of the free open-source version control systems will work. Pick CVS, SVN, Git, or Mercurial, set up a repository on a server, and install the Tortoise client for it on all the relevant Windows machines. Then set up remote vaulting for the repository, preferably to at least two locations. If it's just code, you don't need a commercial system. (Microsoft (Visual SourceSafe is rather retro.)

    The version control system will work fine. It's getting users used to the idea of check-ins

It is easier to write an incorrect program than understand a correct one.

Working...