Slashdot Mirror
Ask Slashdot: Explaining Version Control To Non-Technical People?
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?"
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, roll your own git on Linux, 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.
My work here is dung.
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.
What is there to sell? Install svn or git and start using it. If there is a problem then I would look for a new job as they don't have a clue.
You need to explain the concept of configuration control. Configuration control can be done with or without version control software. Using version control software just makes the process easier.
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.
Need a Python, C++, Unix, Linux develop
If they're not technically people, what are they?
"Ever wanted to go back to a version of a document you wrote a month ago? Compare it against what you have now to see the changes? That's what this is."
That's the question for the boss. Perhaps you should tell him/her that it's like "track changes" for computer stuff.
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.
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.
Sig: I stole this sig.
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.
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
Light cup, beer drink, thin so chain, neck turtle fat, man I won't say it again
"It's like massively-multiplayer undo!"
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
Tell Him/Her that's it's like Wikipedia.... when changes are made, if anyone makes a bad change, it makes it easy to revert to the good working version.
simple. Easy. Something they should be able to relate to and it gets the point across without embarrassing them or making them sound like an idiot.
A lot of people are familiar with Sharepoint or something similar or a Wiki for version control of documents.
Tell them Source Control is like CMS for source code with (most times optional "approval" process).
As for cost, if you use subversion you are only out the cost of the disk/cpu server consumption it will entail (make sure to factor backups into your cost analysis however).
After working with researchers for five years, I would suggest you try comparing it to tools or constructs that said researcher would be more likely to use. Anything from "It's like track changes in Word." to "It's like having a grant manager for the web site. A tool to help keep track of everything that is going on with the project/site/code and verify/approve changes/additions/disbursements." or even (since you are talking social sciences) "It's like having a census for the web site." It's really all about finding a vernacular/construct that is relevant to their work.
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.
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.
-- Mike
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 version control system, and price the one you want out of the range so that the solution is to hire a version secretary whose job is to track all that by hand, and you ask the VS for permission to work on a piece of code. That'll make your life harder, and cost less than some of the complex options (though not scalable, it'd be fine for most places).
Learn to love Alaska
Many nontechnical users may be familiar with the "track changes" feature in Office apps like Word and Excel. The "track changes" feature is a basic form of version control . I would compare it to that or something similar. In my experience explaining technical concepts to nontechnical users, they tend to be receptive of comparisons with the familiar.
If you ever saved a file under a name such as mypage.html.Jun12 or, worse, mypage.html.old, you basically used a ghetto Version Control. You already agree that it is useful, so let me show how easy it is to do it properly, in a way that will remember everything about who, when, and how changed every file, and will prevent accidental overwrites and editing conflicts.
Explain it as being like Apple's Time Machine or Microsoft Office's Track Changes. It's a really smart backup system that lets you roll back to a specific point in time, see when someone changed something, see who changed something, and see why someone changed something (via the commit log message).
Explain that it's a morale issue, makes developers feel they're working on a solid foundation.
org.slashdot.post.SignatureNotFoundException: ewg
http://lmgtfy.com/?q=git+for+designers
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.
I hate being bipolar; it's awesome!
If they're reasonably young, make an analogy with game saves in a video game and they will understand perfectly.
but then I would, technically speaking, have to kill you.
http://lmgtfy.com/?q=what+is+version+control%3F&l=1
Seriously, why is it that you didn't ask google the question?
--BitZtream
"If we're ever audited, they'll want to know we're using version control."
The best single answer I've ever found to work with management - they don't like getting stung by auditors.
But the real answers are - Not using it is unprofessional, bordering on negligent.
There is no cost to version control.
Version control makes your life easier.
It makes fixes easier.
It allows collaboration.
You never need to keep crappy old code "just in case we need it again".
No more "oldfile.old.new.old.bak.2007(2)"
If you use something like github it provides an offsite backup.
Even in a team of one, using version control is easier, more efficient, and all 'round better than not using version control.
Not using it is some dark ages shiz.
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 notebook is checked in, the librarian makes a complete copy and stores it in the reference section of the library. At any time, regardless of whether the original notebook is checked out, anyone can go to the reference section and read the reference copies of old versions. And, just like a regular library reference section, you cannot check those old copies out; they are read-only.
Version control provides the functions of several kinds of software rolled into one:
- Backup, so you never lose your files, including older versions
- Collaboration software, allowing multiple people to work on the same file
- Logging software, so you can see what was changed when by whom
The above may not be 100% exact, but should be enough to convey the benefits.
One of their students was "Little Bobby" T.
OT: I wonder how many /.'ers saw this comic in their mind without having to follow the link? :)
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I watched this today, which is a different take on this which may help some folks that don't exactly get collaboratively managing information.
http://www.ted.com/talks/clay_shirky_how_the_internet_will_one_day_transform_government.html
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.
HA! I just wasted some of your bandwidth with a frivolous sig!
Why not get the free Perforce - at www.perforce.com
A small configuration like yours (about 3 people?) does not need a license version - and the best part - it is Free
.... particularly a departmental one, where there's been a history of ad hoc development that met the needs of the staff well when the applications were first developed but there is no management buy-in to maintenance of a code base and no culture of rigour in the developers who may have been brought in and out to do piecework. It's also a standard approach for a manager in an academic position to want a justification, which is fine, although sometimes they want to make insightful comments/recommendations from their academic disciplinary perspective which is often not useful. Academics also ask for a lot of information - after all, their job predisposes them to be analytical - whether they really need to or not. If you really need to sell it, the image in the first reply is helpful - http://upload.wikimedia.org/wikipedia/commons/a/af/Revision_controlled_project_visualization-2010-24-02.svg talk through that, explaining how branches and versions are used in the development process - contrast with the opposite scenario when versioning is not used.
These are social 'scientists'. That would work for businesspeople.
I think he should obfuscate the explanation with lots and lots of multi-syllabic synonyms for common words. Spend lot of time babbling about multiple perspectives on project documents and avoiding conflict.
I think the key analogy is lending library. You checkout a document to modify it, the library keeps track of changes and makes sure everybodies work is backed up. Requiring a checkout prevents multiple people making modifications and work being wasted. Everybody can have a read-only copy or authors can keep documents private. Lone geniuses can keep their whole project checked out for months or years, though it should be discouraged. Paranoids can keep their projects encrypted (use encoded) to keep the CIA out of their thesis', though that wrecks change tracking.
Your job is to translate the above paragraph into social 'scientist'. The resulting document will be many pages long, have no words shorter then 3 syllabils, and require a week to untangle. Your explanations up to now have no doubt been too clear for them to grasp. Use their jargon, not yours. It will suck.
Be careful or you will admin the departments records for them and still not have version control.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
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:
Imagine you write a book. You write 10 pages. You photocopy them and store them somewhere safe. Then you write another 10 pages and in the mean time you made corrections to some of the previous 10 pages. Total 20. You photocopy all those 20 pages and store as well. That's what version control is without optimizations.
Simple.
"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.
AccountKiller
"I don't know how to explain source control without waving a gun." -- The Profound Programmer http://i.imgur.com/I4C16.jpg
The manager will want to know is the cost of implementing version control worth the risk of not having it. (Even though most version control systems are free - the time for the contractors to implement them are not) Your job is to show what the risks are for not having version control and combined with the total costs that it would take to implement a solution. This is why they want a task brief. It is then up to them to make a decision if they can afford the risk.
*bleep* management and their proposals. If you are making software, you need version control. Just use whichever of {rcs|cvs|svn|git|mercurial|bzr} you want, but start doing it now.
You can write proposals for something expensive when you are bored.
Here is my list of what I would put into a report on the benefits: 1) History/Debugging: It lets us review what changes are made when and why. This can really help debugging because we often know when the problem started showing up so we can see what changed and what might have beend the cause. 2) Undo: We can go back to an earlier version when some changes we made were bad or headed in the wronge direction 3) Collaboration: It has powerful tools for collaboration that make it easier for team to work on a project at the same time 4) Sand Box: It provides a way to create local trial versions that are not shared by everyone and can be merged in later. 5) Backup: Organized system of backup and retrieval, nothing is accidentally lost and we don't each come up with out own way to back it files 6) Versioning/Stability: It allows us to have some people fixing bugs in the version everyone is using while most people are working on new features. So no one has to deal with an unstable version in order to get an update with fixed bugs.
If you have to explain it, easy:
Imagine you are writing up your tps report. You submit it, but the boss says nope change these things. You make the changes. Your boss turns back to you and says, I liked it better before.
Revision control is a system that will give you back the original document even though you saved over it.
Revision control gives the programmer confidence to make changes because you can always go back to the old version if something goes wrong.
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 annotations for the changes they'd like to see. Those are returned and then merged to incoporate all the changes. The next year you are releasing the brochure again, but it requires updates. This continues every year. But one year the department head says they want to make the brochure more like the one they did in 2008. So you're able to pull up the older design from the archive.
Changing it to a real world workflow they can understand will help them see the benefit.
As for cost...I would simply estimate the cost of having xxxx amount of gigabytes of redundant storage - at least mirrored.
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.
<blink>down the rabbit hole</blink>
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?"
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.
Get off my lawn.
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 time a glance at the title pages shows the gradual changes in the document. It contains an entire history of all the changes and what they were.
(Parenthetically, have you ever encountered HP doc changes for something like HP-UX? Let's just say they waste a whole lot of cardboard and plastic wrap.)
In any case, use a library-like analogy, and it may get through. Good luck.
How about a moderation of -1 pedantic.
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"!
...so in this case I'd tell them it's like MS Word's "track changes" feature. And then, building on the other comment about explaining how it helps, you'd walk through an example about reviewing changes and approving some and rejecting others.
I know the analogy doesn't hold up if you're talking to a technical person but you've already made it pretty clear that they're not technical. Put it in terms they understand even if it's only partially correct--you can baby-step them through the rest as the need arises.
Some people have mentioned "backups" as an analogy. While partially true, when you come to talk about backing up the repository (for centralised version control), you'll get the inevitable why backup backups? Given they are researchers, I suspect the best analogy is multiple authors writing a text book. Often writing a book is broken up into chapters with each author writing a chapter. Version control effectively keeps a copy of each draft but rather than keeping copies of each draft, version control manages that process for you. Sometimes multiple authors work on the same chapter. In this case they may take turns. Again, drafts follow a sequence and so this essentially becomes the single author problem with a slight level of complexity. However sometimes someone might review a draft while you continue working. You will receive the review and incorporate changes into your current draft. Verson control provides a process to handle this without having to meticulously go through the review to decide on changes that need to be incorporated. Then explain that unlike authoring a book, a software developer could be generating drafts very quickly - multiple times a day. Other analogies may be the practice of keeping a log book where version control is logging changes to code and (hopefully) reasons for those changes.
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 :)
-- Ed Carp, N7EKG erc@pobox.com PGP KeyID: 0x0BD32C9B What I'm up to: http://intuitives.mine.nu
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 complicated build process to get the newest version running. Just relax, init the repo, add the files, and you are rolling.
-><- no
So, I teach an intro-level class at a community college on software project development. It covers stuff like version control, issue tracking, continuous integration, unit testing, and so on. We use both Subversion in Git in class for exercises, but I try to talk about general concepts and describe how other VCSes do things, too. With that in mind, my intro to version control speech usually goes something like:
The first thing I'm going to talk about is what's called a version control repository. The repository is a lot like a normal folder on a computer; it holds files and folders inside it. The thing that makes it special is that it remembers every change ever made to it. Every time a file is added, deleted, moved, or changed, it remembers what time the change happened, what was changed in the file, and who changed it. The repository exists on a server on the network, so whenever anybody changes a file in it, their changes are shared with everybody else. (note: I know distributed VCSes are different, that's a topic for a few weeks later)
What kind of things can you do with that? Any ideas? (wait for suggestions from the class) The most important thing is that you have a backup of every version of your files that has ever existed. If your hard drive catches on fire, you can get your files back from the repository. If you make a mistake in a file and need to undo your changes, you can always get the previous version of the file. As long as you're using the repository, you never have to worry about losing any data or making any mistakes that can't be undone.
It also makes it easy to coordinate changes to files with other people. If multiple people are working on the same file at once, the repository can show you the differences between the files and indicate who changed what. If a bug is introduced into your program, you can get the files from a previous version where the bug didn't exist, and you can easily see what has changed in the files since then and who made the changes.
So, to recap: version control is like an unlimited "undo" button that is backed up to the network, shared with other people, and can tell you who changed what. It can be used for a lot of different applications, but you can probably imagine how this is really important for software development.
(and that's how I explain to newbie coders)
Karma: Terrifying (mostly affected by atrocities you've committed)
I've been doing version control for years and never even got a Twinkie.
Me neither. But here in Texas we get paid in BBQ.
Create a short file. A couple of lines will do. Any text you like. Check in into RCS. Modify text. Check it in again. Check it out at different revision levels (co -p). This is what we had before. This is what we have now. Simple. Easy to understand.
Then you can get into multiple branches and merging and whatnot and confuse the heck out of 'em.
The takeaway will be the first part, the simple stuff. "We can get back to where we were." The complex stuff will fly over their head. But they'll just figure if the simple stuff is so incredibly useful, the complex part must be even more important to have!
Really folks, maybe you should take time between coding sprints for some English lessons, basic writing skills, even Toastmasters.
This story simply floors me. Two times they asked you if you needed any stuff, and both times you said YES, wimpty dimpty floodle dee bee.
You should have said, YES we need a server to store all the hundreds of files we have and keep them organized and backed up. It would cost around $3000 or so.
What on earth is this "source control" you are blabbering on about. Isn't that a piece of software that YOU install on a server? Yes, YOU!!! Why are you bothering these kind people with stuff that is simply not their job. They offered to help you do yours, so tell them how many bucks it costs to get what you need, where it can be bought, and get on with it. And don't forget extra hard drives for backup copies. Extra servers would be nice, but the hard drives are essential.
A few years back my group worked with another group on testing new silicon. Our bosses were completely different, starting at layer 2 management (they were hardware, we were software, level 1 management was the CEO). They used shared Windows directories, no version control. It was common to get email "would whoever broke foo.c for lib bar.a about 20 minutes ago please fix it?". And I have to admit, I broke their build more than once when confusing my editor on my working code with my editor on their reference code.
After about 18 months they finally agreed to use source control. Very good, thinks I. Then one day I start looking at their version history. I saw they were overwriting changes, doing odd reversions, and generally messing up.
Then I figured it out. Every night they would delete the entire repository. Then they would re-submit the current contents of their working directory. Every odd version was a "new file". Every even version was "delete file".
I sent them mail saying they were Doing It Wrong, got mail back saying "It Works For Us", I pointed out the changes they made but lost, they said "Works For Us", I never mentioned source control to them again.
I would probably briefly mention this incredibly important aspect of source/version control, strange that I haven't seen anyone mention it.
Tired of my customary (Score:1)
"Some people have mentioned "backups" as an analogy. While partially true, when you come to talk about backing up the repository (for centralised version control), you'll get the inevitable why backup backups?"
So what's wrong with having "multiple" backups? There's no need to go into more sophisticated non-IT analogies when a backup is the one thing any responsible administrator should have as a matter of policy.
Want something more sophisticated? Tell him/her that's it's a backup would multiple levels of undo. "Undo" or Ctrl-Z is a familiar enough concept.
Leave the details to your fellow techies. Or you'll suffer the fate of those climate scientists who don't get a good press because they're so subtle with their description of what's happening to the weather.
Blame; being able to know who inserted racial slurs into your product is useful for knowing who to fire.
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?"
Have gnu, will travel.
Come on! It's not like Apple isn't using the concept to explain things already.
Version Control is nothing more than a multi-revision filesystem. Like Git. You can explain it that it acts like a timemachine, so if you make a mistake, you can go back to a version that does not have a problem and and see what exactly went wrong and fix the problem in the current version.
It also tracks who did what, where and where.
You don't need to explain anything else.
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 that developer's successor. No more dumpster diving through the old guy's hard drive to find all the files that make up the system (and wondering if you got the right ones). The new guy simply checks out the current version from the source control server and he's ready to roll. Not only does he have the current version, he has a *complete* history of *all* the changes made to the software and why. You can toss the old guy's hard drive in the trash. This is even more so if you have a build automation tool like Maven that allows you to retrieve all the library and framework files you need to set up a build system on a new machine.
For teams working on software simultaneously, source control eliminates the kind of three-legged race you have to run to make sure all your changes work together. Sure, some of the time you have reconcile incompatible changes, but it's much easier when you can retrieve, compare, even *merge* different versions of any file in the system.
Source control is essential for support and for responsible management of software development investment. It allows you to find out not only what changed, but why. It allows you to recreate your software (or web site) at any point in the past, by version number or by date, do whatever you need with that data, and then simply toss your copy of the source files away -- all that old information can be instantly recreated any time you wish. No more confusing and redundant files and directories on your development machines (e.g. "myfiles.save.c" -- why was I saving that? "myfile.new.c" -- when was it new, and what was new about it? That kind of malarkey is unprofessional).
By removing the clutter, bookkeeping, and errors created by juggling versions of files on your hard disk, version control becomes a kind of safety net that allows you to be more creative, trying things that might break the system in full confidence that you can get anything you want back any time you want. You can also branch of speculative versions of the system, throw them away if you don't want them (and get them back if you change your mind), and merge those branches (with a some work of course, but it's a lot easier knowing you can't possibly screw anything up).
Version control is so immensely useful, I think people should use it for *everything*, including personal documents, papers, proposals ... anything whose integrity or history is important. Researchers who keep data in Excel spreadsheets or Access databases ought to use version control on those. They ought to put their scholarly papers in version control too. The problem is that most source control systems are overkill, but if you have an in-house expert (a professional developer) he can train people on the stuff they need. I keep all my personal writing in bzr, which isn't necessarily the system I'd choose for software development, but it's simple, easy to use and cross platform.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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 philosophy. But, in this particular category of software, every single particular example happens to be better than every commercial one. So if you trying to imply otherwise with a slashdot post, you are either looking for ideas on how to market a turd commercial version control, or you are hoping to get people to take a look around and notice what you are selling. Not going to happen.
Any guest worker system is indistinguishable from indentured servitude.
If they took an hour to read this, it would probably (mostly) make sense to them and enlighten them:
http://betterexplained.com/articles/a-visual-guide-to-version-control/
We can write code faster.
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 that code up on github. Hell just show her the github branch tracker, and you'll probably have a convert.
Then you can explain version control best practices and how to use your version control effectively to work on single features, code branching and merging. That stuff's a bit harder to sell since it actually involves a bit more work for developers, but deciding that you only want 3 of the 5 changes you've been working on in the last release cycle and actually being able to create a production branch for that by merging three feature branches is kind of a win. Also, being able to check out the branch of code that production is currently running without any changes you've made since then, also a big win. Have some jackass accidentally format one of your production servers and see how big a win that is.
If you're feeling adventurous you could even talk to her about a backup policy...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
And what it costs. Even more important than how it helps. When I do these kinds of presentations (and I do a lot of them), I always provide the easy/medium/hard scale. Provide trade-offs (even the stupid solution has to have at least 1 advantage. Which you beat to death in the medium and hard catagories.
I also ballpark costs. I usually express costs as a loss of productivity ("Of 40 hours per week, I spend 5 hours looking for current versions, and 3 hours housekeeping. 20% of the week. That's approximatel $xxx/year in costs. [$xxx is the percentage of your salary you spend working on manual version control and housekeeping] and you can buy a yyyyy for that," where yyyy is something real-world, like the cost of VC software or upgrades to the IT infrastructure, etc)
When you show folks how much money they waste because they're lazy, its astonishing how quickly they want to be come educated and 'good stewards'.
Whether to use version control or not is a technical decision to be made by a technical person or team*. If you have to justify that to someone who does not have a technical background, you have bigger problems than not having a version control.
* I would like to say version control is no longer an option but standard industry practice, only I have seen development teams no using any.
First, technical people need to understand version control. Few do. If you are reading this and think you understand source control -- ask yourself this question. How do I know if the source control system I am using at work today, is aligned with how the company does business (i.e moves product from concept to the customer and EOL). If the team is using CVS, Subversion, Perforce (the family of tools that are trunk/branch based) -- and not a web company or a chip company, then the team is most likely using a source code control system that is inappropriate for their SDLC
In addition to the various use cases for Version Control in development, with roll your own software it can also make your DB backups more meaningful.
Often DB backups are kept for years (13 years is common with systems I work on) but the application code is not. So years later a DB instance is refreshed but the code that make sense of it is not available. A good version control system can help address this scenario.
E.g. I once spent about a fortnight trying to make sense of a 6-7 year old DB backup because it was required as part of a discovery process for a court case. In the end I had so many proviso's (The meaning of this filed is unclear, this depends on a config item, etc) that I felt my work was a piece of fiction.
And no, the app was not backed up. It still existed though on the network and could not start-up with the ancient DB schema.
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 .
-rozzin.
Wow, despite the stereotype you peddle to the angry at the world basement dweller *portion* of Slashdot, these same social scientists you mock include most of the founders of any significant human civilization and the documentors/philosophers of high level thinking; which I'm told is something required even to do even "real" science. Heck many of them were "real" scientists as well and not just wimpy philosophy space wasters. Back when people were only considered wise if they valued both understanding the physical and the metaphysical. These beta test scientists understood silly things like maintaining analyzing history, being able to speak/write coherently, and many other social innovations were key to a society where ""real" science could be performed. These proto-social scientists found patterns and themes in history, created structured language, documented things, and otherwise enabled the wide spread acceptance and clear reasoning for the social contract distinguishing humans from other animals through mutual generational information transfer. This is what makes us able to understand the value of interaction over pure instinct and creates an environment where experiments and science can exist. Humans didn't do much of anything to progress up until this point. Before all this a lab would have been pointless and useless, specimens/materials from far away lands would be impossible to acquire or identify, the concept of the academic collaboration/review model would seem pointless. Heck good luck building anything even resembling a piece of modern scientific equipment over the course of a lifetime. Even if you did you would be all alone in figure out how to use it. Though none of that would interest you because you likely would be too focused on survival, unfamiliar with anything you hadn't personally experienced, and without any way to compile, compute, or transfer knowledge to future generations. So science, "real" or "social" would seem like a total waste, and in the just another thing distracting you from the next meal. Luckily some early humans understood what you do not. Thank them everytime you do anything that you wouldn't see your dog do.
Hey slashdot, my first post
This will explain everything to them:
http://www.ted.com/talks/clay_shirky_how_the_internet_will_one_day_transform_government.html
https://bitbucket.org/ - free hosting for unlimited repositories for up to 5 users
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 a recipe, a kitchen, and 3 cooks.
The intended project is the recipe. The cooks as the programmers, and the kitchen is the programming environment.
Where the version control fits in? The food, of course !
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.
In this way, non-geeks can get a clearly picture in their mind, on how a version control software functions.
In my career spanning decades, I had to explain all kinds of very geeky things to very very awkward non-geeks, and I have to make them understand the details without making them jumping off the 55th floor.
Muchas Gracias, Señor Edward Snowden !
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 and visibility that takes work.
A sincere supervisor will not ask a question to sincere developers when really and truly the supervisor has no intention of taking action on the matter; eg. there is no need to sell anything.
Does anyone out there have any tips on how to sell version control to management?
get them to watch Primer. tell them that if they had had version control, they would have understood it.
Most technical people make the mistake that they should give all these technical reasons for something to non-technical people. What you should be doing is giving the high level picture. Here's how you do that:
"Developers screw up. A lot. Sometimes code breaks and we don't know how or why, or who did it. Keeping track of what/who/when and being able to go back to an old known good version saves us tons of headaches, and thus saves us time and money. When we don't do this we waste time and money and create stress. These are bad things. Source code control is extremely cheap, will pay for itself the first time it's used, and just requires the discipline to use it, which we already have".
That's actually about all you have to say. Anyone that's not a total moron will understand that going back to a known good version when something breaks is valuable.
AccountKiller
Does a plumber need to explain why he needs a basic tool to do his/her work?
You just say, we need version control to be able to work organized and cooperatively on our source code, here is my favorite choice. I talked with my colleagues and we agreed on it. It costs n dollars and Mr./Mrs. Y will take care of it as the admin.
Yes, this. How will the people using it benefit? For example:
1. It makes it easier for multiple people to make changes to the same document at the same time.
2. It keeps a history of all changes ever made, so you can go back to an older version if you make a mistake.
3. Users can provide a comment with each change to say why they made it, and describe what is different. Later, when looking at code, you can look at who made a change and why, which can help you understand the code.
4. Different users can use different versions of a project. For example, say a researcher uses a piece of software to generate data for a paper they're writing; that researcher can continue to use the same version of that software, while the people writing it can continue making changes for other researchers. Down the road, if anybody ever wants to go back to look at what was used to generate that paper's data, it's easily accessible. And if they never need to do that, there aren't files cluttering everything up.
That said, if you're just looking for version control for you and the other web developer, I don't know why you're waiting for your supervisors to approve - I know people that run a version control system just for their own documents - code and otherwise. Everything they do gets version controlled. The only reason you need your supervisors to intervene is if you want the whole department to start using it, or if you want the version control to be supported by an IT group or something like that. Otherwise, just tell your supervisor "Yeah, there's this thing called version control that will help us stay organized. I'm going to download which is free and open-source and we're going to start using it. It'll make our job easier, and we'll be able to get more things done."
keeps a backup of all older versions, so it provides a reliable rollback plan in case the unthinkable happens, and as an added bonus it prevents new bugs from happening by keeping track of all changes.
Don't be afraid to lay it on real thick with buzzword bingo terms like backups and rollbacks (or better yet, disaster recovery measures) and preventative processes and process management and all that jazz. It's all true... More or less... Hell they won't know the difference anyway.
Managers understand the word 'Desktop', and that's perhaps the extent of their technical knowledge.
Tell them that a version control tool is like a shared desktop that saves every version of a file ever put on it by any user and never empties the trash can.
If they can't grok the utility in that, then God help you.
As for cost, an open source tool is probably all you need even though a certain popular commercial product I've based my career on has free academic licensing (name withheld as to not be accused of shilling), so you'd just need to be sure to include the human cost (time) for setting it up, coming up with a workflow, training and any day-to-day maintenance the IT support team might have to charge back to the department. Even though the costs are not monetary, if I remember anything about school, they still need to charge and track every resource that goes into something.
I think this is a very good approach. Thanks for the suggestion!
Essentially, you have to pick them up from where they are, so
Step 1: tell them about a case that everyone already experienced: having multiple versions of a document flying around by email, everyone makes little changes, noone really knows which version is now complete.
Step 2: make the anology: the svn/git is someone who is there to take care of the mess. Instead of mailing the file to each other all the time, you just ask that person "give me the latest version", and once you are done editing "here is my updated document".
Step 3: extend to other scenarios, eg. "two users changed the same text fragment at the same time", "somebody wants to know what was changed in the last month", etc.
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?"
No, he works for the U, the work he does is on systems for the Soc folks. So his boss is either in charge of the Department or higher up in the administration. The ledger analogy should work, another good one would be the student transcript. You don't just give a degree, you track individual grades for every course ever taken, and the situation where a class is re-taken would be especially helpful as an analogy.
Mattyj and a few others had some good info. Use analogies, but tailor them to stuff your faculty/admins are familiar with; grades, exams,meeting minutes, billing , other frequently-touched projects. and ABSOLUTELY, document costs. if possible, show what you can project costs are for NOT using it - based on some tangible event or cost. Hardware: needs storage, and if a dedicated server you can help harden it by keeping it on private address space. Plus, many mgrs like fully-contained costs, not a partial share of use/maintenance on a shared box. Warranty or service contract, installation (if racked), and costs if you need to shift/share costs with telecom/network for campus, new/repurposed electrical feed, UPS & backup systems. Operating System: license & support costs if any, and human time to train up, and document, backup, train others Software, lots of open source stuff - weigh the support ( even poor support is better than a project that gets abandoned) cost and support to learn/almost master that particular application.. and document and train.. Projected Lifecycle: how long will this be viable, before it needs to be replaced or moved to a new OS/ new piece of hardware? -- will your data be in a simple-to-migrate form (txt, csv, xml).. even 10 yrs or so from now? --- forecast interim upgrades, failed hard disks, and other 'reasonable to expect' products -- what happens to old data from old code projects? secure storage and old storage on this box is wiped? or will everythnig stay as long as hard drives can hold it? Universities don't have anywhere near the perceived resources that some have said. Student labor is rare - especially in a job where they do more than answer phones between facebook and homework. Spare equipment is becoming the standard equipment.. I haven't been able to test a new server OS for 3+ years. All live deployments on the only equipt. available.
...anymore than you would a compiler or threads or recursion.
Just make a free GitHub account and push.
Your time is better spent coding and doing the right thing than trying to explain it to social scientists.
It happened to me once and all I had to tell to convince the client was a version control system would keep track of all changes so if anybody messes up, we won't lose anything saving tons of time and money :).
1. Sit non-techie in front of Wikipedia and navigate to a page of their choice.
2. Click the "Edit" tab and show how easy it is for anyone to modify the article.
3. Explain the productivity benefits of low barriers to entry -- no locks, no approval process.
4. Ask what the downside would be. Hope for an answer about dangers of vandalism or poor-quality contributions by unqualified people.
5. Click the "View history" tab and show how all edits are visible and never lost.
6. Show how easy it is to "rewind" to an earlier version of the article. At this point, the non-techie should start to understand why Wikipedia works and is not just a mess of low-quality, vandalised articles.
7. Help by pointing out how every edit identifies the contributor, or at least their computer (IP address) so they can be blocked.
8. Explain that source code control is like Wikipedia but for computer programming -- nobody's work is ever lost, all contributions are identifiable and traceable, rewinding is easy, and people can build on each other's work quickly and easily.
9. Explain that modern (distributed) SCC systems are much more powerful than Wikipedia in terms of what programmers can do to organise their work and their teams.
What I'm thinking is the cost of lunch vs. an online source control system annual subscription.
I'm sorry if I haven't offended anyone
Go down explaining the easiest catastrofies senarios that you can avoid using vc such as:
Code back up in stages, conflict resolution, blame.
Also adding the fact that is free if implemented locally, and very cheap using a service online is a good argument.
It sounds limitating but managment care mostly about gaining more and cutting costs, so.
1. It makes it easier for multiple people to make changes to the same document at the same time.
5. It makes it harder for multiple people making changes to the same document to mess up each others' changes. If they have a minimum IQ.
(One of my colleagues once had a fight with some other developer who apparently didn't quite get the concept - used Perforce and checked in his changes, overwriting everyone else's changes in the same file and breaking everything. Repeatedly. After being told not to. After being explained why not to. )
A version control system is just something that lets multiple people on multiple computers work on a single project consisting of many files at the same time and be reasonably sure that they have the same versions of everything as everybody else.
Furthermore it is usally easy to get a copy of earlier versions of any of the files in the project.
At the moment I am looking I am looking at sparkleshare (http://www.sparkleshare.org) as a way of making it as easy as possible for a non technical user to interface with a version control system.
Anyway. To describe revision control to a nontechnical person, get away from software. Use a novel as an example, which consists of different chapters. Revision control will help the writer organize the various drafts of each chapter and which drafts together form a draft of the actual novel. Revision control also helps the writer keep inconsistencies out of the novel (e.g. the murderer was character A in early drafts, but changed to character B in later ones, etc).
Get *his* attention with this:
Now that you have *his* attention, you can sell *him* on
so why did the gender of the boss change when moving from the article to your head?
I'd explain version control as a time machine. you can go back to old versions of code anytime, any version. plus it saves the code in a safe place and everybody who needs it can access it. and finally it ease development when more than a developer is involved.
also, there are a lot of free alternatives, so all the cost is really the time you spend setting it up and maintaining it.
Why are you trying to explain version control/revision control from a technical perspective? This concept existed long before IT started using it, it is about as ancient as writing itself. IF they have never heard of or handled versions of documents in written form let alone electronic form I would be very very concerned about their capabilities to successfully do any sort of research.
Maybe management think you're paid well enough to buy your own twinkies.
Are you kidding us all? Do you actually know anything about source code control? You took as much time writing up your troll bait as it would have taken to download, install, and do a basic tutorial of git or mercurial. You don't need to ask anyone, just do it. Don't confuse your boss with the details.
They ask you what you need, so you'll say "Version Control.
She then asks "Why?" and "Cost? ".
I guess she did not ask "How?". Its not important that she understands "How?", its only important she understands "Why?".
If she did ask "How?", she actually meant to learn "What is the impact on other people and their work process?".
The questions "Costs?" can be answered with "Just some time to set it up the free software, and for productivity i recommend buying SmartGit for 300 bucks.". If there is other stuff/hardware you need, just determine a budget, make a plan, take decisions and work it out, and don't bother her with details, only when there is an strategic/tactical choice to make.
I'm flabbergasted that this (just doing it yourself, not wasting words on it) isn't how you approached the "problem" already, it it was a problem.
Hivemind harvest in progress..
Their is version control and source control. Sometimes version control can be overkill. Take a web project. If you are constantly maintaining code for a large site do you really want to rebuild everything as a new version when you only need to update one or two files. This is one area where some of the free systems are lacking.
The cost of a version control is mostly drive space nowadays. The software is free and drive space is cheap. In contrast, NOT having version control can be very expensive indeed.
Above all it shows what the latest (and hopefully best) version of a file and where to get it. The whole logging / change story comes second. I don't understand what the problem is with setting up a simple subversion server for yourselves. There must be a pc around that is always on. Just start for yourselves and then slowly spread it among the other people, explaining them how to use subversion, update, etc. Start with the more open-minded people first. Use subversion, not git. Subversion is more user friendly and you don't need the distributed stuff.
Theres ALWAYS a cost. And its cost that management worry about.
Its just not an option to say.. 'I need this, its a free download therefore its free'.
As a short list of things to think about when you think something is free and management disagree.
1) Time (your time isn't free, you get paid right?)
2) Resource (does it need a server/disk/bandwidth?)
3) Training (you already know how to use it?)
4) Support (you're going to look after it yourself? But that stops you doing your 'real' job)
If you work in any sort of corporate enterprise where money is the bottom line there always a cost involved. At its very basic, if you're messing around installing some free version control software you're not actually writing the code you're paid to write. There may be a cost/benefit pay off, but then you need to be able to quantify that. Welcome to business case hell.
The justification is derived from the question What is the most important part of debugging? to which the answer is Laying Blame[1].
Or, stating it more professionally: the most important part of debugging is finding the cause, which is more quickly found if you can see:
- What changed recently?
- Was it part of some bigger group of changes?
- Who made the change?
If you know who changed it last, you know who to ask questions of.
[1] We can prove that laying blame is the most important part of debugging by observing the behavior of any group of developers after a bug is discovered. The conversation immediately takes the form "Did Mary touch that last?" and "Wasn't Joe making changes there as part of the new authentication stuff?"
Make sure that along with any tools you need that you also have the server/hardware to host the solution.
This includes:
- server hardware
- maintenance contracts
- resources allocated to manage the hardware
- backups
You have a team writing a book. Different people responsible for different sections of the book, with a lead editor making certain all the parts are accurate, not loaded with typographical or syntactic errors, and the content is factually accurate.
As people begin submitting work and the outline look more and more like a book, you want to store the latest version on a daily basis. This is important for a few reasons;
1. If you find a problem, for instance inaccurate content or a quote without a legal release, you can just roll your book back to the prior version before the last check in.
2. You can do a partial or full rollback, If the error only effects a small section of the book, for instance the work of only one author, then a partial rollback may be appropriate.
3. The notes containing the metadata for your book, allow you to see how the book is evolving, and make subtle changes in the road map to accommodate new content or features that your book should include.
This structured environment gives you both insight and control of the PROCESS by which your book is created and with a team, is essential to making certain everyone is honoring the conventions of the Books themes and presentation style. It allows you to prioritize, emphasize, reorganize, and expand the scope of the book in ways that a haphazard approach would be completely unable to do. It also let's you measure the metrics of text generation and who your heavy lifters are. In short it gives you the handle on your process to ensure a logical and orderly development for writing your book, while also providing you with the information you need to be able to determine if your original plans hold water or not.
Programming is the process of organizing language into well structured logical blocks to accomplish work. A versioning system allows to apply the same kind of logical process to the development of your application. It provided you with a natural framework upon which to build while giving you the freedom to investigate logical branches and parallel development. It allow you to manage all the dangly bits without letting them drag in the dirt.
Just apt-get install git-core.
"The more prohibitions there are, The poorer the people will be" -- Lao Tse
have you ever screwed something up and wished there was an undo button?
version control is an undo (and redo!) button for very large projects with many people working on it.
Is free for the usage you are talking about (less than 5 developers), and supports both git and hg.
https://bitbucket.org/
When a supervisor says:
That means she is stalling you. She has no real intention of giving you the tools and just wants your to go through some meaningless exercise so that, in the end, she has a tangible record of your attempt to pass around and prove that you really didn't need the tool. In the mean time you will continue your stellar performance without the tool proving to all that you never needed the tool in the first place.
Time to quit.
You have to talk to her in a way she can relate to: she is expecting to hear of a a tool that will make an instant impact on the work she now sees and perceives as "pleasing" and, as long as she assumes this, she won't understand. Besides what you already told her, stress out that it is a tool designed to dramatically improve the workflow process: making things happen faster and with less errors. But, anyway, why not just use git?
Let it spread unofficially and once they get the meaning imprinted in them and the only remaining trouble is inappropriate name, just think of something noble sounding, like "Asssaver".
Troll 2.0 Fear my asocial networking!
A photo album of your family. It records "snap shots" of time ... forever ... so you can at ANY TIME go back and look at them, compare them, learn from them.
You're supporting researchers right ? Version control for researchers is invaluable : it allows them to go back to a previously done experiment, and re-run it in the same conditions (code-wise). Or re-check how a particular aspect of it was handled. Or compare two experiments. Tell them that and they might take notice.
On the other hand, they are social researchers, and you can't VC humans. Yet.
My mother didn't have a computer until she was over 60 years of age. She is computer illiterate to an extent I'd say contradicts being alive.
I explained it to her that way:
You write a text. You save it.
You change the text.
So you have two versions, an older one and the current one.
You want to keep both versions.
If you just save the text, the old version gets lost.
If you rename the current version, you have both versions.
But you need something to remember:
a) you have two versions.
b) you know, where they are.
c) you know the naming scheme.
There is software, which does this for you. It keeps track of these issues and allows many other things.
I did ask her questions which showed me if she did understand the matter to that point.
Glad to hear you are trying hard to be a good employee. With that in mind, there are two types of bad worker:
* People who never do what they are told.
* People who only do what they are told.
This is a clear instance where the right course of action is simply to go ahead and set up what you need. You don't need to ask permission. Just do it. Once it's done and all code has been moved into git/svn/whatever, you can either tell the supervisor what you've done, or not. If the supervisor isn't technical then there's no need for them to be troubled.
The closest analogy I can think of is: you started your job and found spilled milk on the floor. The correct course of action would be to clean up the spill, not to ask for permission to clean up the spill, or ask your supervisor how best to clean up the spill. You know what needs to be done, so just do it.
rooooar
Version control is a critical basic dev and admin tool.
Once you figure that out, schedule a 8 hour meeting with all stakeholders and several layers of management to see if you're allowed to adjust the brightness and contrast settings on your monitor despite not being A+ certified, and/or if you're allowed to use the new fangled pageup/pagedown keys instead of hitting up and down arrow a lot of times, after all the IT helpdesk will require extensive training and documentation on how to be responsible for pgup/pgdn and its not written into any existing procedures nor are there tracked, graphed, and reported performance metrics on the use of pgup/pgdown keys. Also ask for permission to wear light gray socks instead of regular gray socks, that might have to go up to CEO level for approval of course.
If you don't see where I'm going, your boss Might be a micromanager so start looking for work. Emphasis on Might because reality could vary from "hey cool I just wanna learn more" all the way to "thou shalt hit the exact keystrokes your lord and master has specified in the exact order at the exact time", and there's no way to tell on slashdot.
Or just tell the boss, the other devs will laugh at you and steal your lunch money unless you install and use git, which happens to be free...
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
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.
This is likely true. My technical nature betrays me here. :-)
But I think the most important thing is to use a story. Explain it in stories and scenarios that are geared towards their worldview.
Need a Python, C++, Unix, Linux develop
I think some of the people who replied to me had really good points and suggestions for how this approach might be done better than I described as well.
Particularly this one, and this one about focusing on costs.
Need a Python, C++, Unix, Linux develop
Demo this: open up a document in your favorite editor/word processor. Now, go in and change all the 'p's to 'q's, using search and replace. Easy right? Now change all the 'q's to 'p's. This does not put things back the way they were, does it?
No problem, just use "undo" a couple of times and you are back to the original, correct document, right?
That's when you point out that without a version control system, you have no "undo". Without it, your only recourse is to go through that document one letter at a time and fix the p's and q's by hand.
Then draw the obvious parallels to source code bugs, emphasizing that finding bugs is much harder than finding misspellings.
QED.
There's an obvious deficit in the concept of Version Control.
It's not automatic, It requires the user to "decide" when something should be "Versioned" and perform an action.
The action is usually entangled with the event or operation of "Committing" a change and as we all know most programmers "can't commit".
The biggest problem I ever saw working with a coding team was the efforts they went to "uncommit" and to "back out a change" from the "Version Control" system.
The next biggest problem was "reconciliation"
When faced with a choice between their code and someone else's conflicting code, they will always choose theirs over someone else's and not expend the effort to understand why something else was committed. Then they will slice and dice a project to prevent conflicts and "confrontations" which kind of invalidates the need for Version Control.
If you then look at it as a personal tool, you might as well use Dropbox for the repository and save a new version every time you save a file. Which then says its purpose is to save disk space or to "de-duplicate". Of course we've all come into conflict with our own files, in which we don't have time to reconcile and "fork" so that we have both the old copy and a new copy tailored for a particular purpose.
So you see.. version control is more about social interaction and getting people to agree to "talk" and "reconcile" in a formal agreed upon manner, rather than an enforcer and teacher as everyone wishes it to be. It doesn't save yourself from yourself. Its really not much better than an automated backup system with a fancy name an a "Bragging Badge" of honor.
What would I recommend?
A structured shared folder with automatic saves, perhaps some meta documenting system like a version control - but a whole heck of a lot more people communicating, and frequent automatic backups of the repository.
Git's tagline is "everything local". But is that a good idea? Every developer has the company's entire codebase (including history) on his laptop. Which means it's just a tar and an scp away from delivering to his next place of employment.
I'm not a lawyer, but I play one on the Internet. Blog
Your manager doesn't care how you will use it or what the internals are doing in the background. They care a) how much it will cost/save (both in terms of your time and in terms of cash), b) what will it enable you to do (extra services they can sell?) and c) what risks will it mitigate or exacerbate. Give them a couple of buzzwords that they can google if they want to sound knowledgeable (such as Change Management and Release Management).
I usually get a couple people together to do a small demonstration where I give them a subject to write about and have one person write about it. Then I photocopy it for each person in the demonstration and ask them to make whatever changes they see fit. Then aggregate the results into a pile and ask the original writer to sort out all of the changes into one coherent document. If they actually go through with it, or you have to jump in to do it, point out that is what the version system does, as well as keeping track of who each change came from and the ability to view each change side-by-side with a before and after copy with things highlighted in colors that represent addition, removal, and alteration.
Tell them it's like an automated filing cabinet where you file different versions of the files you're working on. If you need a specific version, you can get a specific version, and it keeps everything neat and orderly.
Go talk to the Computer Science guys, and ask them how they get a Linux VMs, or boxes. A large University should have enough resources to setup a VM with some SAN space for this.
Also Rhodecode is a self hosted source control management system, like Github, which supports both git and mercurial. It even has Windows installation instructions, or if you can't get them to install a Scientific Linux or CentOS VM for you.
http://rhodecode.org/
http://packages.python.org/RhodeCode/installation_win.html#installation-win
This is not a difficult thing to explain. Some things can't be simplified any more. The term "version control" is self-explanatory to anyone with an average IQ.
I'd like to plug that back in February, Perforce changes its free edition from 2 users / 2 workspaces to 20 users / 20 workspaces.This means it (bazaar or git, or svn) is now free and you can evaluate it on its merits. Generally these days people choose git, but git is overkill if you are bot doing distributed development. Since you're centralized at your office and not a bunch of disparate developers I'd highly suggest you just start using it.
Also it might be worth your time to just use it for a few versions, then show your boss what it can do by going back through your actually revision history.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Skip the version control, and just say you need a Repository. (Both software and hardware). You need a server to save backups to (manager should be familiar with the idea of backups and why they're valuable) combined with a way to manage changes over time in case you went the wrong way on something and need to back up. Tell them its software to keep multiple, automated backups just in case. Also explain that code is very complicated, and you cannot work on the code simultaneously, so explain that multiple developers working together gives you different versions of the code that have to then be merged / blended together. To make sure that merge didn't mess anything up, you want to keep backups of all the different versions. Pretty simple.
GCS/MU/P d- s:- a-- C++++$ UL++ P+ L++ E+ W++ N o K- w--- O M+ V- PS+++ PE Y+ PGP t+ 5- X R++ tv+ b++ DI++ D++ G+ e++ h-
It also has "snapshots" of particular points in time for all of the files.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
" but had a difficult time describing to her what exactly version control was"
If you can't describe it in a few sentences, then you don't understand it.
Version control it how you keep discrete version of the software. It makes trouble shooting faster, it allows you to roll back in case of a crisis, and allows for cheaper maintenance. You can maintain the current release, while still developing a new version.
If she wants more, list all the issue you had to be paid to clan up that wouldn't happen with good version control.
In most cases, my initial sentence is enough to get the all rolling.
The Kruger Dunning explains most post on
When I moved from academia to a non-software technical company to a software company, one of the best tools I saw was a database to track reported bugs and requested enhancements. This really matters if the entire team is more than a couple of programmers, i.e testers, help desk, documentation. half of fixing a bug is documenting that it is there and how to repeat it. Multiple software users will probably come across. then they can be prioritized and marked as fixed.
We use some over-ornate database form Oracle-PeopleSoft. I do not know what may be free out there.
Like...
Track changes feature in Microsoft Word.
Change orders applied to the contract of building a new house.
Amendments to contracts.
It's just the management of the amendments in a fashion that allows many people to make amendments and figure out when those amendments conflict with each other. Then other tools help you resolve those conflicts and and make everything work in the end.
If the source code is valuable to the company in a proprietary way, you might not want to use an external repository. It depends on the company whether they are comfortable that security measures on the external VCS are good enough. What if the service goes down just when you need the last version to fix a production bug that is costing the company money? What if the external service is purchased by someone aligned with your companies competitors? What if they don't secure the code and someone with admin privledges makes a copy of your code for fun or profit? What if they are hacked? Are these all scenarios that your company is good with.
Of course, you have to compare it to the internal server scenario. Is there support for the internal servers at 2:00 AM when you are doing an emergency fix of your software and the VCS server can't be contacted due to a network issue? Do you have sufficient "data center" security to keep the bad guys out of your code and code history?
It sort of all depends on the code and what it does and the mindset of company management.
I'm sure your manager knows about the "Track Changes" feature in Microsoft Word.
Version control is like that, but for software development.
That's probably the best explanation you can provide.
As luck would have it, yesterday's featured TED Talk was on the importance of version control systems -- specifically GIT -- in non-technical applications.
Seastead this.
There are plenty of great, free, version control systems. I prefer git, but there is also hg, bzr, and of course the good old fashioned svn.
Tell them that without it the Johnson rod will cause a meltdown.
Change Management is a discipline to ensure that the configuration of an item (and its components) is known and documented and that changes are controlled and tracked.
Everyone who works with documents uses some form of change management, from simple to sophisticated systems. A simple system might have the latest copy in the user "Documents" folder and older copies stored in an email "sent items" folder. A more sophisticated process would keep the information in a consistent location and capture detailed information on the important elements of change: What was the change, Who did it, Why did they change it, When did the change happen, and provide the ability to easily retrieve any previous version.
Change Management processes don't require software (you can maintain a log of changes in a written journal), but with the right software your process will be much easier to use and consistently apply. The opposite is also true: the wrong software can make it much harder to manage change and cause frustration and delays, slowing down the change you are trying to manage. It is important that the software you choose is not getting in the way of your change management process.
Modern CM research by firms such as the Configuration Management Institute has shown that the majority of benefits only occur when the change management system can ensure the integrity of all managed items, make their evolution more manageable and the interrelationship clear. The effectiveness can be improved by implementing automated techniques for Insulation, Security and Access Control, Lifecycle Management, Communication and Detailed Reporting.
In summary, Effective Change Management is a process that for each managed item will:
Enable communication and detailed reporting about changes.
CVS Suite contains the features you need to establish an effective Change Management process.
Quoting from a draft for http://march-hare.com/
If you still need to explain version control in non-technical terms, maybe try explaining it in terms of medical mistakes. I'm sure your manager has seen articles about patients who have the wrong leg amputated or been prescribed the wrong medicine. Now she can imagine the impact if someone makes a similar mistake in your software. And you can go on with the analogy by explaining how version control lets you revert to a previous state, effectively reattaching the amputated limb, to extend the medical analogy
If she just needs an explanation of why a service is better for you than maintaining your own Mercurial environment, I think you already have it covered: it will save your team from maintenance effort that you can use to be more productive in other areas, and that the gain in productivity will exceed the cost of the service. (Assuming you have numbers to back that up.)
Making a change to software is like choosing to take a fork in the road - you either change, or continue unchanged.
Version control remembers when and where you took that fork in the road and most importantly provides a map of how to get back to that fork.
By descriptions of VC software here, it sounds like you can also view multiple forks at the same time and judge which one would allow you to arrive at your desired destination.
A version control system came out of the computer field. Formerly, when several people would work on a given program, or even one person, they might accidently wind up with multiple copies of files, all different, and no good way of figuring out which was the good one.
With version control, files are checked in and out, and only edited after being checked out. Once done, you check them back in; and all the versions that have ever been checked in can be reproduced on demand by the VCS.
When you're ready to roll out something to production, you add a label on all of the files that are going into production. If there's a show stopper once it's rolled out, it's trivial to simply extract by label the previous production version and replace the new version in production with the previous working version.
And there is never any question about what the most recent version, or production version, is.
mark
For about the last 80 years social science has been infected with relativism. Which says that nothing is true and everything (including real science) is socially constructed.
Until this mass of stupidity is excreted from the academe, social science is worse then useless. It is circular reasoning at it's worst. Used to justify the prejudices of the social scientists. Hell they study Marx to learn about capitalism. Most think Adam Smith got it wrong and Marx was insightful.
Of course anybody who disagrees will never get a position. Circle jerks abound.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
for Source Code. All the best source code control systems are available free of charge, we just need some modest hardware to run it.
You're welcome.
Facebook timeline for programmers.
http://www.turnkeylinux.org/gitlab Give this to your server team and let them run it under virtualization.
Don't go into technical terms. Don't get even near them. They will probably not understand what you say after 5 seconds and then it's game over.
Version control is THE system used everywhere by developers to keep their work safe (they'll probably like that). It allows them to collaborate (!) efficiently (!) and easily recover (!) from any made mistakes.
That are things that are not too complicated to understand.
Try to explain it to your mother, or grandmother for example. If they think they understand, you're in the right track.
Perhaps try to compare it to writing articles. They should understand that. You keep older versions of the paper, just in case you find you deleted important parts.
Trying to explain branching would probably be too technical already.
Privacy is terrorism.
"It's like "Track changes" in Word, but way geekier. We need it and it's cheap. It'll pay for itself by the end of the month."
Most clients I work with have had good and bad experiences with programmers. That said, they almost never have source control set up. So I ask them if they've ever been ripped off, or had someone disappear with the source. If so, it's a good reason to use source control. If not, it could happen any time if you don't use source control. As a client, all you need to know is that every line of what you pay for is stored, locked away, and safe, the minute you install GIT or Subversion. Oh, and that I'm awesome for suggesting it. You're welcome.
This signature intentionally left blank.
You draw up a budget - include everything: servers, staff, training for the end users.
Also, you make a measurement of the current size of the problem. Take a wild guess about how many hours are wasted by people trying to do manually what version control would let them do automatically. If you have trouble getting numbers, you can always do a survey. Ask people how much time they spend trying to coordinate multiple simultaneous revisions to a group document, then ask them if they are satisfied with the tools they have to do their jobs.
You go to your boss and say, "For X dollars, I can boost productivity by Y man-hours and improve employee satisfaction by 10%. It'll take about four weeks for the pilot project and six months to get the whole company on board."
She won't care how, she'll just say "do it." She won't care at all if your employee satisfaction only goes up 5% (it will - you get to write that survey too) if you are anywhere close to being on time an on budget.
Note that you have to do it without turning the whole organisation upside down. If the staff doesn't know what version control is, it's crucial to start with a small group of volunteers who at least have an inkling that what they're doing now isn't working very well. Use the lessons learned from moving them onto the tool, to fine-tune your strategy for getting the rest of the company to actually use the tool. Remember, from many users' perspective, using version control is actually extra work. It's only the poor sucker currently stuck with the job of reconciling different versions who sees a direct advantage. Education and ease of use are crucial.
I describe version control using a real world example. Company A is having a problem with their warehouse management system crashing every time a bunch of programmers change "stuff" for the month. The system would be down for days while the programmers try to back changes out of the system. Version control software makes it possible to store the previous setups. If the system crashes after a bunch of updates are put into their warehouse management system again, you can go to the version control software and restore the previous known good setup and get the system up within an hour.
Then they say "Oh, it is just like a backup".
Then I say it is better than a backup because with a monthly backup, the point where you save the system, you have to restore the ENTIRE system and that can take a few hours to maybe a day or two. Version control software can back out changes in the code ONE AT A TIME. You will be able to bring the system up, with some needed changes, often before the warehouse even opens. You can't do that with a restore from backup.
Then they get the idea that version control is far better than backup software. That is what most people understand. We in Slashdot know that version control does so much more than that.
The thing I've always failed at is in first announcing what I'm looking for, then narrowing to specific packages.
"What does this computer need?" :"It needs an operating system." :"What's an operating system???"
"erm... you won't get it but I need it...."
Instead,
"What does this computer need?"
"It needs TRSDOS 3.1*"
"Well, what's TRSDOS 3.1*?"
"It's the software that allows us to run programs. It costs $75.00*. The computer won't run without it."
*The name and price of the OS has been changed to protect the innocent poster.
Applying this...
"What do you need?"
"We need GitHub."
"What's a GITHUB?"
"It's a subscription web service for code development management. By providing pre-existing tools it will take away a lot of the time we have to spend managing code development and doing revision and bug tracking, freeing up out time for more code development, revision, and bug fixing. It costs $50.00 per month."
But darn, that's seriously hard, becuase I think in terms of categories of what I need to fix a problem, not the exact tool for what must be done.
HA! I do believe you found the "social scientist" in the room. Good job.
We can all go home now.
It would be worth thinking about how secure you need your code to be before you entrust it to a 3rd party. The services should be secure but it is an additional risk.
What I have in mind here is not so much the actual code but hard coded passwords or even data that might have found its way in amongst the code.
If it hasn't been mentioned elsewhere you can use SVN without a server but with a repository created on a shared file share which might be an option and at least if all the data is staying on the same share you can't be making things less secure than they are now.
I believe that the management you were describing would be otherwise known as clever blonds.
How did they get to where they are in management? Surely they must know about keeping copies. They would if they wrote documents and needed to refer to earlier ones.
Leslie Satenstein Montreal Quebec Canada
Conceptually, version control is like having your own time machine for documents.
Here's a brief summary I wrote about the benefits.
Sometimes I doubt your commitment to Sparkle Motion
If I had to explain then, I would start with "If you had the ability to undo all the mistakes that you did since you were born, wouldn't you be confident enough to try something new? Now apply that for code, you'll be able to try new stuff hoping that all working code is backed up and you can fix things if something goes wrong." Your manager might reply asking you to backup code for the above statement. I would continue "Imagine that you are not sure about something goes wrong with your life, you won't know until that happens. Now unless you have ability to rewind stuff and fix things, you'd be in trouble, that's what version control does to projects, it prevents you from getting into problems." If manager still doesn't get convinced, I'll ask him/her to play Prince of Persia game :P
It's always strange to me that business people understand the importance of keeping track of money, but not other company resources.
To put it in terms they understand, try explaining it in terms of accounting.
Imagine an accountant who only kept track of exactly one number: The amount of money the company currently had.
This accountant might be really good at remembering where all the money is, and can even explain where all of that money needs to go and where it came from, usually. But he only ever actually writes down the current amount.
Throughout the day he does everything on a single calculator, then at the end of the day he writes down the final number, to use as the starting point for the next day.
Sometimes, just before or just after a major transaction, he'll write down the number and maybe the date, first.
But it's only ever one number.
Would you hire that accountant? Would you trust them with your accounts? Even if the accountant seemed really good at staying on top of things?
You can't just keep track of "where you are." you need to know how you got there. You need to know why you took each step along the way.
-- 'The' Lord and Master Bitman On High, Master Of All