It's not really a technical question, but there are several other questions here about source control and best practice.

The company I work for (which will remain anonymous) uses a network share to host its source code and released code.  It's the responsibility of the developer or manager to manually move source code to the correct folder depending on whether it's been released and what version it is and stuff.  We have various spreadsheets dotted around where we record file names and versions and what's changed, and some teams also put details of different versions at the top of each file.  Each team (2-3 teams) seems to do this differently within the company.  As you can imagine, it's an organised mess - organised, because the "right people" know where their stuff is, but a mess because it's all different and it relies on people remembering what to do at any one time.  One good thing is that everything is backed up on a nightly basis and kept indefinitely, so if mistakes are made, snapshots can be recovered.

I've been trying to push for some kind of managed source control for a while, but I can't seem to get enough support for it within the company.  My main arguments are:


We're currently vulnerable; at any point someone could forget to do
one of the many release actions we have to do, which could mean whole
versions are not stored correctly.  It could take hours or even days
to piece a version back together if necessary
We're developing new features along with bug fixes, and often have to delay the release 
of one or the other because some work has not been completed yet.  We also have to force 
customers to take versions that include new features even if they just want a bug fix, 
because there's only really one version we're all working on
We're experiencing problems with Visual Studio because multiple
developers are using the same projects at the same time (not the same
files, but it's still causing problems)
There are only 15 developers, but we all do stuff differently; wouldn't
it be better to have a standard company-wide approach we all have to
follow?


My questions are:


Is it normal for a group of this size not to have source control?
I have so far been given only vague reasons for not having source control - what
reasons would you suggest could be valid for not
implementing source control, given the information above?
Are there any more reasons for source control that I could add to my
arsenal?


I'm asking mainly to get a feel for why I have had so much resistance, so please answer honestly.

I'll give the answer to the person I believe has taken the most balanced approach and has answered all three questions.

Thanks in advance

It is absolutely not normal for a group that size to be working without source control—the size of the largest group of programmers that can work effectively without source control is less than or equal to one. It’s absolutely inexcusable to work without version control for a professional team of any size, and perhaps I’m not feeling creative, but I can’t come up with any reason why you would want to forgo it.

Version control is just another tool—a particularly powerful one, and one which delivers enormous benefits relative to its minimal cost. It gives you the power to finely manage all of your changes in an organised fashion, with all kinds of other handy things like branching, automated merging, tagging, and so on. If you need to build a version from umpteen versions ago, you can check out the code from that point in time and just build without having to jump through any other hoops.

More importantly, if you need to write a bugfix, you can merge it into an update without having to deliver the new features you’re working on—because they’re on another branch, and as far as the rest of the development needs to be concerned, they don’t exist yet.

You’re experiencing resistance because you’re challenging the culture of the company. It will take time for them to adjust, no matter what you say. The best you can do is keep pushing for it, and if the company really won’t budge, find another job that’s better suited to your level as a developer.
