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.

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

3

It sounds like they're not very far from working with a DVCS like Mercurial. The people who drag their feet could still be "using" Mercurial if the existing folder were actually made into a repository. From their perspective it would look almost the same, and you could commit the changes if they didn't.
–
John FisherOct 5 '11 at 22:02

19

UPDATE (Nearly a year after I asked this question): Over the course of the last year, I've campaigned and cajoled and begged and wheedled until I got to the point where I damn near got myself fired for insubordination a few times. I'm pleased to say that the company in question is now finally taking a serious look at source control, with a view to implement TFS after a trial period of a month or so while we ensure all the developers are happy with the new processes. It was largely the positive response I got from this question at programmers.SE that gave me the confidence to pursue it. Cheers.
–
LordScreeOct 2 '12 at 13:57

10

Developers not using source control is equivalent to surgeons not washing their hands or using dirty utensils to operate. It is professionally incompetent and there is no excuse for that kind of malpractice.
–
TimOct 2 '12 at 15:02

1

Even though electricity has been invented a long while ago and is pervasive in our every day lives some people still choose to work at candle light scribbling code on a waxed board using a pointy stick.
–
NewtopianOct 2 '12 at 20:26

31 Answers
31

It may not be normal, but as Treb says, it's probably not that unusual

As others have said, there are no valid reasons for not having source control in a company your size. So you need to identify and attack the invalid reasons:

a) the main one is the status quo: "if it ain't broke, don't fix it". This is difficult: you could start pointing out all the things which aren't working as well as they should (which can quickly get you labelled as a 'negative person'), or you just wait for something to blow up (which might never happen), or you could emphasise all the things that could go wrong. Unfortunately people in charge of small companies are relatively impervious to 'things which could go wrong' until they actually do go wrong...

b) ignorance/fear/uncertainty: "we don't really understand what source control is; we don't know how to use it; we don't know which tool to choose; it's going to cramp our style". This is one reason I definitely wouldn't send them here! It might be a fairly tall order for you on your own, but I think to maximise your chances you need to present a 'turn-key' solution, and not too many variants or alternatives. You need a clear idea of: how you want to fit/transform your working process to work with the given tool; how/if you plan to back-port existing code; how fast you think you can 'train' users and have them up and running; how you can manage the transition period (if there is one); how much it is likely to 'cost' (in hours, if not in dollars).

c) there may be other reasons (previous bad experiences with VSS for example, or having read 'horror stories' about allegedly over-complicated tools), but you'll have to bat those ones individually when you discover them.

There are ample reasons for source control outlined in the other answers. My advice would be to pick out the main 2 or 3 that could really make a difference to your company and polish them up and present them in a meeting to as many of your colleagues as possible. Try to provoke discussion: even if you don't immediately convince them, you will gain insight into what the sticking points may be.

Thank you for the (sadly) neccessary distinction between normal and unusual. +1
–
kepplaOct 4 '11 at 12:58

29

+1 for ignorance/fud. If you're a professional software developer, not using SCM, then you're not. period.
–
Chris ThorntonOct 4 '11 at 20:09

2

Just out of curiosity, who would pay $300 per person for source control (Valut, according to your wiki link), when there are countless free applications?
–
RobOct 4 '11 at 22:17

11

on point 2: I don't see any valid reason for a team of any size (include a team of 1) to not use Source control... ?
–
James KhouryOct 4 '11 at 23:49

1

Another reason that that some small groups do not have version control -- there is some overhead and learning involved in setting it up. You need a server to host the code base. You need to administer the server and the VC software on that server. You need to back up the VC database, create and test a recovery plan and monitor the backups to ensure that that the backup/recovery is still valid. All this administration takes time. In organizations with poor software management, the time developers spend administering the VC system may be punished rather than rewarded.
–
Jay ElstonOct 5 '11 at 18:30

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.

Not to mention that there are FREE source control providers, so it's not as if it's an expensive course of action.
–
MantorokOct 4 '11 at 13:50

9

It can be expensive as far as getting people to change their habits, workflow, and procedures.
–
user1936Oct 4 '11 at 15:39

4

@Rook: Absolutely. But I would rather have a safety net I don’t need than need one I don’t have. I was programming long before I knew what a version control system was. While it’s not a necessity, to deprive yourself of a good tool is stupid.
–
Jon PurdyOct 4 '11 at 17:21

12

I couldn't imagine developing without source control even when I'm the only developer.
–
webbiedaveOct 4 '11 at 17:40

In my experience, it is not the norm, but not as completely unusual as other answers here suggest. The majority of small companies does use source control, but a significant number doesn't, unfortunately.

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?

See this question on SO for a good discussion. The accepted answer says:"There are no good reasons not to use version control. Not one."

Are there any more reasons for source control that I could add to my arsenal?

The consensus among all developers and project managers I have met, and of course here on Programmers and SO is that source control is a must. It's an accepted best practice. If somebody decides to ignore it, he needs to have some very strong and convincing arguments why this is the right decision for him (i.e. a little more than 'we never needed it, so why should we need it in the future'). The arguments you have presented so far are focused on specific issues, perhaps you should try a wider approach along the lines of 'everybody does it, so why don't we as well?

@Martin: It's not that unusual to find 15 people who all suffer from the not invented here syndrome... I would guess that maybe 5% of all small (< 20 employees) companies have no source control. I hope for you that your experience differs form mine ;-)
–
TrebOct 4 '11 at 12:57

6

+1 for not unusual. Some people just don't understand that the benefits of source code control outweigh the costs. They fear the cost, and integrate by copying files or patches into a "central" merge workspace for the "build"; mostly because that's what they figured out would work, and nobody invests in the development environment. Typically this is due to the perception that they have so much work to do on the code, they can't waste development time on the environment. I find the time saved with the more efficient environment more than pays back the investment of a developer working on it
–
Edwin BuckOct 4 '11 at 15:54

Source-control is good for even a single developer team. Any source control system is basically a version control system that keeps the track of changes. Imagine of a single developer, who might have removed some code and feels that the code is now required. Can he get the old code back?

Just go for a tool that helps you. The size does not matter everywhere. The quality does matter everywhere.

+1, I am a currently one developer team and I use source control. I even use source control at home to manage personal documents not related to software development, like cooking recipes and my resume.
–
maple_shaft♦Oct 4 '11 at 11:37

1

+1, Lots of small shops start out using zip files as their archive. Thinking "I may want to get back to this point, so I'll just zip the whole thing". It's not the same, not at all. Once you've gotten familiar with SCM, and the great tools that are built on top (log, diff, blame, etc..), you'll never go back.
–
Chris ThorntonOct 4 '11 at 20:07

5

Another great use for SCM: I come in on Monday, wonder what the heck I was working on last Friday. I just do a diff or look at the last checkin log, and I'm immediately back in the zone.
–
Chris ThorntonOct 4 '11 at 20:08

1

Imagine of a single developer, who might have removed some code and feels that the code is now required. Can he get the old code back? Yeah, I just use the last backup I took by hand, a few weeks ago, and I take backups whenever I want to make a major change. Hasn't failed me yet in a few years, and never needed (or felt like I should've used) source control...
–
MehrdadOct 5 '11 at 2:51

It sounds like you are already using a system of version control, but not a very good one. People already seem to recognize the need version control. You just need to introduce them to the next level -- software version control.

If it were me, I would introduce SCM as an improved version of what they are already doing. I would emphasize how using a good tool will automate a lot of the work that is already going on.

Instead of recording changes in a spreadsheet, the SCM system keeps
track of not only what changed, but who changed it and why.

As a bonus, you can go back to any point in the code's life and see what was actually there.

Instead of having different versions of code in different folders and needing to move/merge things between folders to port a change, you can keep everything in the same place, and (more importantly), let the tool do the merging.

As others have already said, I would expect some resistance, so I would prototype the system by using it on the stuff I am doing.

(BTW, I actually put my Resume and other documents under SVN. Then again, I've been played the roles of Configuration and Integration Managers several times.)

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?

The product you're developing is a version control system; managers are concerned about preventing existing products from influencing the design and implementation of the new product.

Between weekends of BASE jumping and running with bulls, thrill-seeking managers enjoy driving to work wondering whether everything's gone to hell yet.

Avoids hostile takeovers. Who would want to acquire a software development outfit that's managed this way?

Are there any more reasons for source control that I could add to my arsenal?

You're already doing version control, but you're currently doing it in the least efficient, most labor-intensive, most error-prone way imaginable. Using a VCS will save money, save time, and improve quality.

Saves disk space. Most version control systems save only the deltas between files. Currently, you're saving an entire copy of every version of every file. (Backing up all those copies must take a lot of time and space!)

Several developers can work on the same file at the same time and reconcile the differences without too much trouble. Merging changes is of course possible without a VCS, but it's nearly impossible to keep track of who changed what, when, and why in that case.

Gives developers freedom to try new ideas knowing that they can recover any version at any time.

Some people have trouble realizing how bad the status quo is until they see something better for themselves. What you need is a good demo. Show some actual examples of tasks it could improve. "This took me 4 hours to track down with our current system, but this one source control command told me instantly."

Not using source control is asking for problems, even for a solo developer. The simple fact that you can edit ruthlessly without risking to lose anything makes up for the learning effort within weeks or days.

That said, if you can't convince your managers to introduce source control, do yourself a favor and at least use something like git or mercurial locally - if things blow up due to lack of source control, at least you won't be the one who did it.

My company uses GIT for version control. The company is one developer, one CEO, one security guard, one cleaning lady and one recepcionist. All of them are me. Source version control is a MUST everytime.

WTF?! This may be the most ridiculous question I've ever seen. You need to find a new job. 15 developers?! You think that's a small team? This is insane. Manager should be immediately terminated. Honestly, I'm going to have nightmares after reading this question. Please tell us the product you sell so we all know not to buy it! I don't know what's scarier, this question, or answers saying this is not unusual!

If I don't commit several times a day, or at least before I leave for home, I feel like .. somethings missing, somethings wrong.

I once worked in a company with just 2 developers (me + long haired admin guy), back in 1998. Even then we used svn. It's just so convenient.

Several times in my career I lost a days of work because I did something like mv instead of cp and then rm -rf. Made me cry and wander around in the city streets in despair.

I worked in 5 companies over my 13 years of being in the SE, been to some conferences, and never encountered a company not using version control.

However, my favorite interior design company, 20 employees, use a white board for project management + collaboration. They know its plain wrong, but they don't seem to find time to upgrade. Somehow it works though. Don't ask me how.

Be a leader. Being a leader means doing what's right; proactively solving problems. Leadership is not doing nothing because there's not enough consensus. And a good leader learns to recognize situations when one should build consensus and when to do. This is clearly a doing situation. The lack of code control WILL blow up in your faces sooner or later.

Leaders often are not in official management positions. People will follow good, decisive leaders regardless of title.

If your decisive efforts get slammed down, especially if it's from management then it's a clear sign for you to get the hell out of there. It's a drag on your professional development; and Competent developers and incompetent management do not mix, and an incompetent with power will screw you.

This is just an accident waiting to happen. You have no code history, and in one fell swoop, one of your developers could wipe out months of work. As a small company you can't afford this kind of setback.

You are also very exposed on that share drive. Even with a good backup, how long can you afford to not be working. 1 hour, 1 day, 1 week. How long would it take to get a new server in place, restore from backup etc. Again as a small company you probably don't have extra hardware on standby and might not be able to readily drop the money to get expedited shipping etc.

Think about offsite storage as well. A flood or fire is not really that unusual. What would happen if there was a fire in the building after hours. How many months of work would be lost. A managed code repository like github would be valuable for this. Even using a simple SVN server on a hosted service would be a step up in this area.

LordScree, I am in an almost identical predicament as you, my immediate team is about 15 developers. I am in disbelief (almost horror) that source control is not used. My initial response to "we should be using source control" was "we don't have time to implement". To me, like wearing underwear, source control is not optional. After a few months, I too have approval to implement TFS, chosen by the org because it is MS and comes with a 90 day trial. Bottom line, it is very difficult to convince an organization of the need for source control when they've been chuggling along without it. I tell developers that anytime you find yourself backing up files, especially with a date in the backed up filename or directory, is an example of when you'd put something in source control. I don't have any brilliant answers for you, but I do believe this is uncommon. I'm fighting the same battle and will keep you posted on progress. And, hopefully there will be progress else I may looking elsewhere cause I can't work in chaos!

we have 3 members of development staff and use source control. On my personal projects I have one developer and I use source control. It's not just useful for team management, it's useful for being able to get into doing experimental work without fear you're doing to destroy something.

Easiest way to convince management? There's less risk to the overall product, and it'll increase developer productivity in the long run. Both are true as well, and both appeal to managers.

It is by no means a normal scenario and i think you should give a tough fight for getting this setup in your company. It has far reaching benefits and has no point in realizing the same when you approach doomsday and it ain't the situation which fall under If it ain't broken don't fix it

Any reason for not implementing it could be only an excuse for bad work or a blunder waiting to happen.

Just tell them how great its to find what the app was on 1 Jan this year

how about hey this functionality was added in March i think we need to expand a bit more on this.

Wow this bug 154256 has been fixed in this commit.

i can branch out the app and send out the deployment no problem guys you can carry on working.

This can go on and on ... (remember to add comments on commits later on else that would be coming in as another question )

I use version control for my one-man projects and my work projects, where we have upwards of 30- 40 people working on the same code at once. Version control has its organizational advantages, but the ability to revert files and stash changes can really take the headache out of managing code... and in the end that is the best scenario for a programmer, so they can just focus on coding.

Reasons to support not using version control are fairly limited. All that I can think of is the technical aspect of things.

There is too much of a learning curve to convert your entire staff's workflow to incorporate a versioning system to be cost effective.

Your project manager does not feel that it would be beneficial to introduce the overhead into the workflow of managing and maintaining a repository. (Primarily an issue with older Versioning Systems)

There are many reasons to use a versioning system. At the very least stop moving things around. Work with patches. Versioning systems can do exactly what it is that you say you do.

You can work on the next version at the same time you are doing bug fixes and release them separately.

Instead of moving files from one location to another to work on it you can create a branch and merge it into the master upon completion.

Each developer can have their own copy of the source code to prevent the issues with the same project open on multiple machines.

Accidents happen, if the code becomes severely broken all you need to do rollback to the last working revision number.

Version control works well paired with bug trackers and continous integration systems.

I personally as a one person team use versioning, bug tracking, continous integration, code review, code consistency checking, unit testing, selenium tests, source code analysis, and there may be more I'm forgetting. I admit, there is a slight learning curve. There's also a tradeoff of additional administration time necessary to the addtional steps you automate. In my experience, the effort saved outweighs the additional administration time.

On my first serious job in 1990 I was the only developer working in my department and didn't know to use source control.

Pretty soon thereafter I learned, from then on I've never seen a project that didn't make it one of the first things they set up.

I nearly lost all my work at that job because I deleted a folder at the wrong level. Luckily I had brought a copy home on a 5" floppy the week before and was able to re-create the weeks work in a few long days.

So I guess I'd consider it acceptable if it was the first project for everyone on the team and nobody knew better, but if even one person could actually explain the benefits and the team still didn't listen I'd re-categorize my opinion of the group from "naive" to "dangerously incompetent" (Resistance to using a tool with such widely-demonstrated benefits is almost criminal--it's like if your team didn't trust "Compilers" and insisted in doing everything in assembly language).

Where I work we have the same problem. I'm currently trying to slide source control in "under the radar" to get around the same issues you have. I use fossil for the projects I develop personally.

I recently got a fossil server set up on the company LAN, so now its even more convenient. I'm hoping that as I demonstrate the usefulness on some smaller projects that I'll undermine the resistance and move us away from the status quo of network folders.

The biggest reasons I've heard for not using fossil, or some other VCS are:

Many of the "programmers" are script kiddies, and won't understand how to use it

Those who could learn, think it is a nuisance to use

These people are the old guard, comfortable with the network folders, so everyone should be

No one has time to set it up right, or learn how to use it

While the features might be great, none of them are necessary

As you can see, I'm trying to get around these by demonstrating that it's simple to use, already set up, easy to learn, and the features are completely worth it.

Finally, even if you don't get them to use source control, it's all in a network tree. Fossil can version everything in the entire tree, and you can set it up to run whenever a file change occurs, or at least every hour. I've done that for some of our projects that "didn't need source control" and it ended up allowing me to roll back to a good version when something went wrong.

Do it right, and they won't even know you've done it. Then you can be the hero who restores the broken build, and demonstrates how useful your tool is.

Now that DVCS tools like Git and Mercurial are available, and incredibly easy to set-up and use, there's really no excuse for even a team of 1(!) not to use source control. It's not about size of team, it's about having a commented history of your changes and the ability to support workflows such as fixing production issues whilst working on a new release, and tracking the state of the source code for different versions.

If I were offered a job in a team that had got to that size, and not one of the developers had suggested using a VCS, or if "management" had prevented them, I'd turn it down flat. It's just not an acceptable way of working these days.

You should get yourself a GIT version control immediately. You can use it even from Google Code Project Hosting. When the others see you commiting changes in just a click while they manually copy things, perhaps they change their mind about it.

Wow, just wow. While I don't think it's the best way to handle code control, it's not entirely unusual I worked at a company with 6 developers and no source control was used, they kind of had their own internal way of managing files, a release manager and whatnot would oversee all changes. In-fact the mantra was that new functionality could be added in to projects as long as some kind of switch was wrapped around the functionality.

For example we were working on a b grade social network written in PHP and the client wanted functionality to be able to subscribe to a users profile. Basically the functionality was wrapped in a check like this if ( ENABLE_SUBSCRIBE_FUNCTIONALITY == true ) { then execute the code }

The place I worked at as well never had more than one developer at a time working on a particular file, mostly everything was modular so in that instance there was no need for source control. However, I believe the advantages of source control far outweigh the disadvantages of not having it in most cases.

The very fact your company is resorting to spreadsheets documenting file changes and what was changed when something like Git or Subversion can handle that for you is just absolutely ridiculous.

The most important factor is that your customers are forced to the last 'instable' branch and if your contracts with your customers makes you responsible for deploying instable versions, your company is losing money. You should really focus on release stability here. This is the main reason for source control, and as it seems your main failure. The others will not be improved that much by using source control as you already have alternative systems in place.