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?

  • 28
    Key piece of missing info: What is your role on the team?
    – Morons
    Commented Nov 28, 2011 at 22:32
  • 124
    Is life really long enough to waste years of it working somewhere like that? You have a team of co-workers who do not wish to work in a competent and professional manner, and management who don't care. You can do better. Commented Nov 28, 2011 at 22:56
  • 10
    About not being used to source control: if this is a real-world project, it's time to get accustomed to source control.
    – compman
    Commented Nov 29, 2011 at 0:23
  • 16
    Either change your workplace, or change your workplace. Whatever you decide, don't hesitate. Commented Nov 29, 2011 at 15:15
  • 13
    The idea of a developer having previously used source control and not loving it is almost beyond my comprehension. Perhaps they used it wrong?
    – jhocking
    Commented Jan 30, 2012 at 14:11

15 Answers 15


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...

  • 15
    -1, "No professional developer today, or for the last 20 years, has resisted source control." - total nonsense, and totally dogmatic. I suspect you are defining 'professional' as 'someone who develops like you'. Commented Nov 30, 2011 at 4:47
  • 76
    @Grandmaster: Are you saying that it's acceptable for a programmer to not use source code control, or are you objecting to my being too dogmatic? Of all the things I can think of that are not open to negotiation in 2011, source control would be at the top of my list. It appears that 27 others agree with me. A DVD burnt with each release, or a copy of the source tree into a folder with a date is arguably source control.
    – mattnz
    Commented Nov 30, 2011 at 7:10
  • 9
    I'm saying the statement that all professionals use source control is provably false. I know plenty that dont, some whom have 'resisted' it. Source control is a tool, like an IDE. Professionals use the tools they think are best suited to the job. If they want to use source control, good for them. If they dont, thats their prerogative. You claiming that its 'not open for negotiation' is irrelevant - I wasnt aware you were appointed the sole and final arbiter of how people should write software. Personally, I'm not so presumptuous to assume that I know better for everybody else. Commented Nov 30, 2011 at 7:42
  • 45
    @GrandmasterB - One could argue against practically anything with the presumption that we accept anecdotal evidence. Of course 100% of developers do not use source control. Of course, there is a case or some small % of successful edge cases. Best practice is to use source control. It's safe to assume that any developer who says they work on a team that doesn't need source control is a cowboy. Not that cowboys can't code, because they can and often very well in fact. They just usually cannot work with others who also can. Commented Nov 30, 2011 at 16:07
  • 6
    I would like to add that this is not even an attitude issue. This is a management issue. Any software/embedded design manager SHOULD know the inherent dangers from a lack of source control and should take steps to remedy this. The server should be locked down to read-only for direct user access, and only checkins accepted. If merges are 'difficult' perhaps they have chosen the wrong career. There is a difference between a hack and a professional. That all being said, see if they'd be more apt to use something other than TFS. Its what I'm forced into right now as well, and it's not my favorite.
    – MattG
    Commented Jan 30, 2012 at 23:27

Sometimes, real world issues make it impractical to use.


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.


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.

  • 3
    "they failed". False. They were undermined by a reward system that's rewarding bad behavior. More training is required. Only, the training needs to fix the reward system, not simply explain how to point and click in the tool.
    – S.Lott
    Commented Nov 28, 2011 at 22:43
  • 2
    @P.Brian.Mackey: "We had training sessions, two or three". Please update your question to contain the entire story. Be sure your description is complete in the question. Do not introduce new facts in comments on a specific answer.
    – S.Lott
    Commented Nov 28, 2011 at 23:23
  • 2
    Ok, the obsession with training is wrong - its a management/policy/environment issue of which training is an aspect but all the training in the world is no use if they can ignore it whereas they will learn (sink or swim) regardless of training if they can't do anything else.
    – Murph
    Commented Nov 29, 2011 at 11:42
  • 1
    Keeping your job is a good reward system. Modify source code directly 3 times, and you are fired will keep people in line :)
    – user25446
    Commented Nov 29, 2011 at 12:28
  • 8
    One of my classmate from a VLSI class made a transistor a few nano-meters wide and a couple of miles (yes miles!) long that fit the specifications. His reply to me was "All I know is that my shit works." I had more tolerance for people back in college. Now I would hate to end up with someone like that on my team. I believe that some teams should be trained, and some should be waved good bye to. Life is too short to hate one's job/colleagues.
    – Job
    Commented Nov 29, 2011 at 14:46

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.

  • I agree in principle, but it depends heavily on the RCS in question. TFS really sucks! There's a reason that Microsoft no longer uses it internally, it really sucks. I remember when Perforce was the king of scale in the RCS world, but that is no longer true. Git and Mercurial easily surpass its scale and are easier to use and maintain.
    – jwdonahue
    Commented Jun 25, 2023 at 7:09

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.

  • Good suggestion, great in fact. But, management gave me the red light on CI. No funds for a VM or physical server. No time allotted for setup either. Commented Nov 28, 2011 at 22:55
  • 7
    Funds for a CI server? It funds itself. Show how long it takes to do a manual deployment with a video if need be. Then explain this is done several times per day. Times several developers. And it should pay for itself in saved time in a month.
    – CaffGeek
    Commented Nov 28, 2011 at 22:58
  • 7
    Hell, run Jenkins on your own machine then. Commented Nov 28, 2011 at 23:03
  • 6
    +1 for lock down the folder structure. Take their server permissions off em and they will HAVE to follow the correct route (through source control)
    – Mauro
    Commented Nov 29, 2011 at 16:39

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.

  • I too think that when developers are complacent for being stuck behind the times, they are usually following the axiom of "if it ain't broke, don't fix it". Most of the places I worked had the same cowboy mentality, because 1. because there's a large computer literacy gap between developers and their managers or 2. there are so few developers that there is no skill hierarchy, or Sr. employee in their company really means "I worked 10 years doing the same stuff I've done in my first".
    – Chris C
    Commented Nov 30, 2011 at 3:24
  • 2
    A shared network folder with shadow copy is a form of version control. A very poor form to be sure, but it is one nevertheless. Commented Dec 2, 2011 at 23:55
  • 6
    I always ask what source code control system is in use at an interview. When the CTO of one company said "What's that" I ran away.
    – Zachary K
    Commented Jan 30, 2012 at 13:58
  • Shared network folder: Done that. In 1987. Developer A made changes locally, then developer B merged then to the networks server manually. Worked well with three clever developers.
    – gnasher729
    Commented Jun 15, 2020 at 18:57

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.

  • lol, good suggestions. Most of this has already been done. Manager says "yes we have to use source control". But, the team does not use source control. I tell the manager and mgr just says "yes we need to use it". Nobody is scolded. No enforcement. Commented Nov 29, 2011 at 15:12
  • 3
    @P.Brian.Mackey - Sometimes you just have to go all BOFH. Once I went on holiday and a contractor working for me spent the whole week surfing dating websites. When I got back and discovered this, his computer developed an inexplicable TCP/IP access problem that I was unable to fix. Have your boss take away their rights to hack directly on the server and force them to go through TFS for deployment and they'll soon clean up their act or quit, either way you win.
    – Mark Booth
    Commented Nov 29, 2011 at 16:10
  • The Keeper of the Source idea is a good one. You might get them to send you their changes -- or at least let you know they made some and update your repo from the diff with prod. Or run fswatch and have it commit to the repo when the files change. Commented Apr 3, 2019 at 17:52
  • Agreed. As usual, humans are the problem. Commented Jun 22, 2023 at 17:17

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.


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.


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).


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.


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.


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.

  • This is the only useful answer. I am sorry, but it is Commented Jun 22, 2023 at 17:29

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.


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.



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.

  • 1
    Team Foundation Server is a pretty different beast than SourceSafe. The comparison is not fair.
    – pap
    Commented Dec 2, 2011 at 14:29
  • The core of my argument has very little to do with TFS. The fundamental problem is a historical lack of using source control of any kind. Commented Dec 2, 2011 at 15:39
  • Do they know it's different? I didn't. Commented Dec 2, 2011 at 22:19
  • @Hiels Basjes - Do they know what is different? Commented Dec 5, 2011 at 14:49
  • That TFS is different from Source Safe. Commented Dec 6, 2011 at 21:58

Not the answer you're looking for? Browse other questions tagged or ask your own question.