How can I convince my department to implement a version control system?

Question

I recently joined the IT department of a big insurance company. Although the department's title is "IT", a lot of code gets written here; Java, JSP, JavaScript, COBOL and even some C++ from what I've heard. All the programs that allow insurers, brokers and the rest of the tie-wearing, white-collar workers to issue new contracts and deal with clients runs on the code produced by this department. I've been told that the department is pretty good by the parent company's standards and that we've even received an internal award or two. We're 17 people in the department, split in smaller groups of 2 or 3. As you might've guessed from the COBOL part further up, the average age is over 40 years (as a point of reference I'm 29 yo).

Right now, there is no version control system in place (there exists a general backup scheme though). When needed, files are passed around through shared folders. Usually there's one person in every group responsible for copying the "final" version of the files back to the production server. I find this absurd and even a bit dangerous.

How may I try to convince management that we should implement a VCS scheme in our department? I've never deployed a VCS myself but every other place I've worked at had one. I think I'll hit a "we've been OK until now, why bother" wall from the first step, coupled with the age of most of my co-workers that will feel this step is an unnecessary hurdle.

I know the basic advantages of VCS (traceability, granular backups, accountability etc). I'm looking to back my case with realistic cases and examples of real added value over the implementation costs, not just a "but-but-but, we must have a VCS you fools!" :-)

Answer 1

You don't necessarily need their permission.

Install svn on your machine, start using it, and then start convincing your fellow team members to use it too.

Then watch and see what happens.

Edits

• The basic idea of this is that it's easier to show than to tell.
• It's a great idea to support your ideas with a working implementation/solution.
• Of course, if you succeed, and they want the system used department/company wide, you must be prepared to support the transition, know how the software is to be installed and used.
• Going ahead and using something accepted in the industry is faster than having discussions on what system should be used.
• There is a good change that this will get you noticed. You may also get your peers respect and support.

As suggested, the same approach can be made on other areas:

• issue/bug tracking systems
• quality tools
• time tracking
• continuous integration
• a wiki for knowledge base, HOWTO's, guidelines, tutorials, presentations, screencasts
• different IDEs and tools
• build tools
• automated deployment
• various scripts that would save your team time

.. any item that will visibly add quality to your work, but doesn't (yet) disrupt existing methodologies and practices.

Answer 2

Joel Spolsky has an excellent article: Getting Things Done When You're Only a Grunt

Quote

Nobody on your team wants to use source control? Create your own CVS repository, on your own hard drive if necessary. Even without cooperation, you can check your code in independently from everybody else's. Then when they have problems that source control can solve (someone accidentally types rm * ~ instead of rm *~), they'll come to you for help. Eventually, people will realize that they can have their own checkouts, too.

Answer 3

Management? I will put bold the expressions and words you should use:

Your should display some examples how a VCS will prevent losing money to the company if some error/bugs or disaster happens. It will be faster to solve all problems, so maintaning the systens won't be so lazy and people become more productive.

You should also mention that implementing a VCS has no costs.

VCS will also give advantages for backup all the existing code. So, all the code will be safe.