Convince the Company I Work for to Implement Version Control?

Question

I recently began working at a small company as a software developer. Before I started, their only means of version control was Microsoft Word documents and Excel spreadsheets. Now that I've started, I'd like to get some form of distributed version control in place (preferably Git or Github).

Version control, as a concept, makes life, organization, and stability much easier for even singular developers, but the company I work for is hesitant. I know with time they might come around, but it's something I'm getting anxious to implement as staying organized is extremely difficult without it. Things like code branches and rollbacks are difficult, manual tasks that could be completely automated with version control. As a whole, version control would make my life easier along with the lives of other developers that might join me or come after me.

How can I convince them to get version control implemented sooner? Should I try to convince them? Should I leave it be and wait for them to come around on their own or reemphasize the importance of this even though I've already talked to them about version control as a possibility?

Answer 1

As with any "how do I convince them to change this?" pursuit, start by making sure you understand the answers to the following questions:

• How did the current situation come to be? Did it just grow that way or did somebody make a decision? If the latter, why?

• What are the real and perceived barriers to change? Money? (That's usually minor compared to the others.) Training? Down-time while people learn and switch systems/processes? Schedule risk? Comfort?

• How is the status quo working? You already know some things that are working badly or you wouldn't be proposing a change, but what's working well?

I think developing software without source control is a terrible idea. But I don't get to decide how your company works, and from their point of view, you don't get to decide unless you can make a convincing case. Making that case starts by showing that you understand the current situation thoroughly.

So start by gathering that understanding, and then share your analysis with the team. Be fair and open -- fair or people won't listen, and open because anybody who wants to should be able to offer input at this stage. Once there's a general feeling that you could probably do better -- do better and it won't hurt too much -- then you can proceed to evaluating specific options, doing test-runs, and so on.

I saw my current organization move from cvs with one main branch to Perforce with per-release branching to a more-complex system of feature, task, and bug branches and complex integration processes. All of the stages were right for their time but not forever. Change has always been slow, thoughtful, and methodical, but it's happened. The changes that people have tried to rush were the ones that did the most damage.

Answer 2

Put together a written proposal on the pros of using version control over the current system. Put together what the minimum barrier to entry into using this technology would be. This could mean starting with a local install of git or svn on your local machine to see which works best for the company. Make sure to plan on having the old and new way both be viable at the same time. Managers HATE a dead switch to a new system. Once you prove that your new system of version control works, you can ween them off the old system. You really need to stress the pros of using version control, and the cons of doing it the old way.

I would suggest looking into TurnKey Linux Virtual Machine instances that can run on windows, or any box pretty much. This will get your version control up super fast, and hosted over the local network.

Answer 3

Take a look at Joel's classic article Getting Things Done When You're Only a Grunt

The first two points address your question directly:

Strategy 1: Just Do It

A lot can be done to improve the project just by one person doing it. Don't have a daily build server? Make one. Set your own machine up with a scheduled job to make builds at night and send out email results. Does it take too many steps to make the build? Write the makefile. Nobody does usability tests? Do your own hallway usability tests on the mailroom folks with a piece of paper or a VB prototype.

Strategy 2: Harness the Power of Viral Marketing

Many of the Joel Test strategies can be implemented by a single person on an uncooperative team. Some of them, if done well, will spread to the rest of the team.

For example, suppose nobody on your team can be persuaded to use a bug database. Don't let it bother you. Just keep your own. Enter bugs that you find in your own code. If you find a bug that somebody else really should fix, assign the bug to them using the bug database. If you have good bug tracking software, this will send them an email. But now, you can keep sending them emails if they don't fix the bug. Eventually, they'll see the value of bug tracking and start to use the system as it was intended. If the QA team refuses to input bugs to the bug tracking system, simply refuse to listen to bug reports through any other channel. About the three-thousdandth time that you say to people, "listen, I'd love to fix that, but I'm going to forget. Can you enter a bug in the system?" they'll start using the database.

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 4

At first there should be a red light. CVS is there for over 20 years. If the company has failed to implement any version control system, it means they are out of touch with current industry standards. They are just happy with things working, they don't research, don't implement new technologies etc. It happens quite often, especially by small companies, which create their own world. Big companies are recruiting often, therefore the idea flow is faster.

You know things the people there don't know, but according to your profile, you're only student. You have little or no practical experience, which means, they probably won't take you seriously. If you'd try to convince them to your ideas, they can take you for theoretical know-it-all and ignore. It doesn't need to go that way, but it's just quite probable.

I've experienced something similar in my first job. The technologies used there were very outdated, but after trying to propose something new, I've got a label of someone who is criticizing everything, although he haven't done anything himself. So in the result, my opinions were taken less seriously than the opinions of the complete newbie.

Now I'm in much better position, because I can recommend some solutions from my commercial experience, and I'm actually expected to do so. But you don't have such comfort yet.

So you have 2 options. Either you just adapt to standards, optionally installing SVN or GIT on your private computer and using it as a merge helper (eventually someone may note the advantages) or try to convince others, where you can win (SVN implemented) or loose (label of Brainy Smurf). From my experience, I think you have more to win as to loose. Working in company using outdated technologies isn't good for a beginner - you need to learn new technologies to fill your CV and increase your chances for better job in the future.

Answer 5

First, get to know why there is none already. May be water cooler chat ? Apart from what everyone else has suggested -if you are so passionate about source control, if I were you, I would do this :

1. Create a small setup on my local machine and code a small employee details like project.
2. Document various use cases that could happen in a development environment which may particularly be bothering you in your current environment.
3. Request my manager for a meeting and give him a demo of handling the use cases with version control and the current approach the company has and effectively show how easy life would be if there was some version control in place.

Answer 6

I think you need to focus on the benefits of source control that they may see the most benefit to start with. I doubt they even dream branching or merging their code.

Be diplomatic and start with something simple. Ask someone how they keep track of the changes they make. Maybe they manually make a copy of a code file and have worked out some folder scheme? Although this works, ask if they are able to put a comment about the change they made. Sometimes a developer works on a project for so long she relies on memory. Adding a new developer to the team will begin to expose this flaw because you'll have to ask everyone directly about what they did instead of being able to easily access it and read about it. But who knows, they may have great documenation. They've just been doing it the hard way.

I know there are tools that do this without using source control, but being able to do a Diff on two files is a huge selling point for me personally. Combined with check-in comments, you get most of the picture of what you would be rolling back to and/or what caused the current problem.

The other features may appeal more to the managers or those trying to schedule programmers for projects (PMs). Branching and merging may appear to be abstract, but the ability for two devs to work on the same code file at the same time could be a huge time saver in their eyes. Because without source control, this is almost impossible (Which is why they don't do it.). That doesn't mean the other programmers won't like it. They're probably frustrated with waiting on one another to finish with a file.

You're going to run into the same problems they've faced. Ask them how they deal with it. The only difference is you have seen where a tool like source control makes it easier, but don't be too quick to judge their current system. They may not face the same problems or have developed good work-arounds.