Search code examples
version-control

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

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!" :-)

Solution

  • 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:

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