How can I convince cowboy programmers to use source control?

Question

I work on a small team of devs, 4 guys. They have all used source control. Most of them can't stand source control and instead choose not to use it. I strongly believe source control is a necessary part of professional development. Several issues make it very difficult to convince them to use source control:

• The team is not used to using TFS. I've had 2 training sessions, but was only allotted 1 hour which is insufficient.
• Team members directly modify code on the server. This keeps code out of sync. Requiring comparison just to be sure you are working with the latest code. And complex merge problems arise
• Time estimates offered by developers exclude time required to fix any of these problems. So, if I say nono it will take 10x longer...I have to constantly explain these issues and risk myself because now management may perceive me as "slow".
• The physical files on the server differ in unknown ways over ~100 files. Merging requires knowledge of the project at hand and, therefore, developer cooperation which I am not able to obtain.
• Other projects are falling out of sync. Developers continue to have a distrust of source control and therefore compound the issue by not using source control.
• Developers argue that using source control is wasteful because merging is error prone and difficult. This is a difficult point to argue, because when source control is being so badly mis-used and source control continually bypassed, it is error prone indeed. Therefore, the evidence "speaks for itself" in their view.
• Developers argue that directly modifying server code, bypassing TFS saves time. This is also difficult to argue. Because the merge required to synchronize the code to start with is time consuming. Multiply this by the 10+ projects we manage.
• Permanent files are often stored in the same directory as the web project. So publishing (full publish) erases these files that are not in source control. This also drives distrust for source control. Because "publishing breaks the project". Fixing this (moving stored files out of the solution subfolders) takes a great deal of time and debugging as these locations are not set in web.config and often exist across multiple code points.

So, the culture persists itself. Bad practice begets more bad practice. Bad solutions drive new hacks to "fix" much deeper, much more time consuming problems. Servers, hard drive space are extremely difficult to come by. Yet, user expectations are rising.

What can be done in this situation?

Answer 1

It's not a training issue, it's a human factors issue. They do not want to, and are creating road blocks. Deal with the broken group dynamics, what is the root cause of their objection - usually fear, is it just fear of change, or is it more sinister.

No professional developer today, or for the last 20 years, has resisted source control. Once, about 30 or 40 years ago, when computers were slow, source control even slower and programs consisted of one 500 line file, it was a pain and there were valid reasons not to use it. These objections can only be coming from the worst kind of cowboys I can think of.

Is the system forced on them making their lives difficult in some way? Find out what it is, and change the system to invalidate the objection. Repeat until done.

I suggest looking at GIT or Mercurial. You can create a repository in each source code tree, they won't even notice and can keep on hacking the way they do now. You can track the changes they have hacked into the code base, make commits, merge them into other source trees etc. When they see you do a merge of a weeks worth of effort into another product in seconds, they might change their ideas. When you roll back one of their screw ups with one command, and save their ass, they might even thank you (don't count on it). At worst, you look good in front of the boss and, for a bonus, make them look like the cowboys they are.

Merging would take not only a great knowledge of the project

In that case, I am afraid you're up the proverbial creek with no paddle. If merging is not an option, neither is implementing it, so you are saying that you can no longer add features you already have in one branch (term used loosely) to another.

If I were you I would reconsider my career prospects...

Answer 2

Sometimes, real world issues make it impractical to use.

False.

If the team is not used to using source control, training problems can arise

That has nothing to do with source code control and everything to do with training. Training is easy, cheap, efficient and done in a matter of hours. Failing to use source code control is costly, risky, inefficient and the problems persist forever.

If a team member directly modifies code on the server, various issues can arise.

That's the training issue. Again. Nothing to do with source code control and everything to do with training.

Developers continue to have a distrust of source control and therefore compound the issue by not using source control

They need to be trained in how to use source code control. It reduces cost, reduces risk, simplifies things and is more efficient. It's a one-time investment that pays dividends every moment.

What can possibly be done in this type of situation?

Start training everyone on how to use source code control.

Update

Developers argue that directly modifying source control saves time.

Since they're wrong, it's important to gather data to demonstrate precisely how wrong this is.

Sadly, however, management appears to reward an immediate response that's costly in the long run.

The only way to overcome this reward system is to

A) Identify that the long term cost is higher than the apparent short term value.

B) Identify the actual rewards that are actually in place that make short term corruption (i.e., direct changes) appear more valuable than long-term correct source code control. Who gets a pat on the head for doing the wrong thing? What kind of pat on the head do they get? Who gives it? In order to fix things, you must name the things that are wrong and the specific manager(s) who is (are) actually encouraging folks.

C) Recommend a revised reward system that values long-term value instead of short-term quick response. Different pats on the head for different reasons.

D) Train folks in the rewards you found for long-term value; value which is clearly larger than the short-term quick response.

Answer 3

Developers who refuse to use source/version control should be fired, simple as that. As you have already pointed out, the inherent risks and costs of NOT using it outweigh any overhead it incurs by many, many orders of magnitude. Anyone trying to argue against this simply should not be involved in software development and I would flat out refuse to work with such people.

Answer 4

We solved the problem by first, setting up a continuous integration server to build our source control into dev. Second, lock down folder access to read only, to prevent people circumventing source control and modifying files directly.

It's a PITA on days where you can't reproduce the bug locally, but other than that it's nicer being able to work, checkin, and move on, knowing it will be pushed to dev automatically by the CI server.

Answer 5

I hear your pain. I've walked into a couple of workplaces to find out their 'source control' was a shared folder on a network drive. The issue is generally not because they believe their approach is superior to anything else, it simply works and they have not ever been introduced to a workflow that successfully integrates source control.

With the "flat earth" team structure you have explained getting the change pushed from the top down may not be the best way to approach the situation. One method that is worth trying is to get buy in directly from one or two of the other devs to allow the concept to gather momentum. Once you have even one other dev on board it will be much easier to spread it to the remainder of the team. Slowly introduce them to the concept, say start working on a little side project, get it up and going in Git, or even branch something hosted on GitHub.

Start simple, introduce the concepts slowly and separately from their day to day workflow. Humans are great at learning things and adapting to change, especially when that change provides direct benefit to them (think evolution). However, when presented with a whole bunch of small changes at once it becomes alienating. Once they have a grasp of how source control works and the advantages it provides then try integrating it into one of your internal project (if you start a new project, this is a wicked time to introduce it). Let the other projects function in the existing way if you like as well, this will be especially effective at highlighting advantages of decent code control.

If that fails, run.

Answer 6

You obviously have the technical skills to identify and fix your situation, your problems are human and process related.

People tend to respond far better to example than vision, so I would suggest "fixing" it yourself:

Take a copy of the latest source, re-structure it to be version control friendly, create a new project with a useful, forward looking structure (work out how you're going to handle branches, where you put 3rd party dependencies etc). You'll probably have to do that in your own time.

Then drag your co-workers and management into a room and show them what software development looks like in the 21st century. Illustrate the failures with your current system and show how they're eliminated with your new structure.

You'll also have to have to set yourself up as the Keeper of the Source - since you appear to be the only one who cares, it's up to you to force people (with whatever technical or psychological means at your disposal) to stick to the plan. Ensure that the only thing going to a customer has come from a build machine out of source control. Ritually humiliate people who break the rules and cause havoc. Bribe them with donuts... whatever works.

If that all seems like too much effort then (as has been said in just about every other answer) - get another job. They're not worth your time.

Answer 7

Step 1 - fire incompetent manager!

If you can't do step 1, try to get the manager to limit deployment to prod to only scripts that are taken from source control. If developers (who should not have production rights on prod, see step 1 if they do) want their stuff deployed it has to come from source control. That solved our issue of not using source control quite nicely back when we first switched to using it for database stuff as well as C# code.

Answer 8

How can someone not want different versions of their files and the ability to see the differences? Forget branching and any of the complex stuff. They don't even get the basics. Directly modifying a production file without doing the most rudimentary change in a test environment is insane. I have worked with some individuals and thankfully we never worked on the same projects.

Your coworkers are too stupid to be lazy. That's a waste of time. All you can hope to do is train your manager. Management should like source control because they like all forms of control. Makes them feel important. Screw the others; fixing the leader is your only hope since you're not able to replace him. Start networking with other competent developers and either try to get them to join your team when you have an openning or get them to hire you at their shop.

Answer 9

It seems from your description that there are one or more problems with the situation - either the dev team is out of control or a bad source control solution was implemented. Either way, it's incumbent on the dev team to use some source control solution - directly modifying source code on the production service is just begging for problems to happen.

From my experience, the first step that must take place immediately is to sync up source control with the production server. This step can be as simple as taking a copy of production code and checking it in - the prod code is presumably the base that your team is developing. This step might need to be augmented by a merge with code that's floating around in the existing source control system. Code should flow from dev to integration/QA (or both), and then to either stage or stage/production.

Next, management needs to mandate use of source control. Quite simply, if the build didn't come from the source control system, code shouldn't get deployed to production. Production access needs to be limited to the support team only, with limited access given to dev to troubleshoot production issues. Developers should generally never do hot deploys of code to production - production problems could definitely happen, particularly if the devs are under pressure.

Management definitely needs to get a better handle on the issues here - it'll be almost impossible to sustain development if code is getting applied to prod directly (and not getting into source control).

Answer 10

Other than the obvious Find a new job, I think the answer is more all of the above.

First go to management to get them on board with moving to and enforcing the use of source control. Then get to what needs to be done to keep things running, even if that means working directly on the server. Start the process of getting everything in source control.

Another option is to make sure the latest is on the server (which you have to do regardless) and start a new repository altogether from the latest. You will lose history, but at this point that is small potatoes.

Answer 11

This is a good example of a project where bad practices have been used so pervasively that it becomes practically impossible to fix it up. Fixing it would require a freeze, so everything can be cleaned up without interruption. Unfortunately, such projects usually are (for obvious reasons) too buggy to be frozen for several months, critical bugs must be fixed every other day.

You might be tempted to fork the project to create a clean version while the dirty version is treated with those daily bugfixes; but the most likely result is that after several months, when the "clean" version is finished, nobody can tell you which bugfixes and changes have been incorportated since the fork (because the same mindset that lets people slip into such practices makes it unlikely that they keep records about the changes they make). The clean version is outdated, the dirty version still kinda works, so what happens? The clean version is dumped, the naysays proven right.

Answer 12

For your own sanity, I'd suggest setting up Git or another DVCS on your own machine so that you can track changes. Import your co-workers' changes into your repository often. Resolve conflicts as best you can. This will partially shield you from your coworkers' insanity.

You've mentioned that management has said that developers should use source control. If you want to be evil, you can enforce this by checking changes into TFS and periodically publishing the repository, thus clobbering any changes that aren't in TFS. (If you're also maintaining your own DVCS, you should keep the two synchronized.) Your justification for doing so is that you're following orders from management. If your coworkers get tired of having their changes overwritten, invite them to use TFS. And keep clobbering changes that haven't been checked in. Continue until your coworkers relent or you get fired.

Answer 13

The real problem is not that the cowboy coders do not use version control. The real problem is that they've already chosen some way of doing things, and you're trying to change their process. The chosen process do not include version control. All process changes are difficult, unless the programmers themselves notice a problem. If there is a feeling that the existing system is good enough, trying to impose some different system is just futile. We are the borg, you will be assimilated. Of course they're trying to fight becoming borg.

Answer 14

Lock down any server other than their development. Use a configuration manager. Do regular identifiable builds (against tags). Tag every change set (ie 1 change set per bug). We also put a tag on each build. Have a QA type system between dev and production (at a minimum). Do builds to QA system using correct build tag. Give them grief for "breaking the build".

I have never run into a situation where I couldn't re-create / fix an issue (that only shows on production). Yes, I have spent hours getting the issue to recreate on a development system (plus when you figure it out you can add it to your regression test).

We did a project with a bunch of cowboy contractors who did all of those bad things. I spend 4 weeks cleaning up after then and then put the above practices in place. The project has had no issues with any of those things since then.

Answer 15

Quote:

The team is not used to using TFS

TFS turns out to be Microsoft Team Foundation Server.

My first instinct says: "this is the latest release of Microsoft Visual SourceSafe"

I would be on the side of you coworkers and go really against this.