Is it unusual for a small company (15 developers) not to use managed source/version control? [closed]

Question

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:

1. Is it normal for a group of this size not to have source control?
2. 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?
3. 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

Answer 1

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

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

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

(Have you read/heard about The Change Function?)

Answer 2

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.

Answer 3

Is it normal for a group of this size not to have source control?

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?

Answer 4

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.

Answer 5

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

Answer 6

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.

• Better process makes it easier to hire and retain talented developers.

Answer 7

Is it normal for a group of this size not to have source control?

No definitely not. When I started at my current company, there was one person whom you should send your changed code to, and he would merge it. I could convince everybody within days to use SVN.

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?

I think the reason you only heard vague reasons is because there are no valid reasons for not using version control.

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

Yes, there are a lot of reasons.

1. Branching gives you the possibility to develop new functionality without interfering with other developments.
2. Each commit gives you the information about what exactly has been changed, who did that change, and when that change was made.
3. You can easily commit bugfixes, and deploy them to the customers, and leave out the unfinished new functionality.
4. You can maintain different versions, if customers are afraid of going to a newer version.
5. You can work on the same project (even the same source files!) with ease.
6. You can easily revert a mistake, with preserving the changes after that committed mistake.

Answer 8

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

Answer 9

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.

Answer 10

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.

Answer 11

I work on a lot of projects by myself and I still use version control. The size does not matter. It always helps to have version control.

There is a reason it is #1 on The Joel Test: http://www.joelonsoftware.com/articles/fog0000000043.html

Also, it makes #2 and #3 on the list possible.

Answer 12

We were in a similar position with a 6 person team a few years ago. One of the developers took the step of installing SVN on a dev server where the shared folder was and just started using it.

Everyone followed suit, and wasn't long before we implemented CI (CruiseControl) and revolutionized our build and release process to include automation and quality checks.

Answer 13

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!

Answer 14

I cannot imagine how 15 developers can work without any source control. However, from:

(...) uses a network share to host its source code (...)

I assume you have created your own poor-man's version control like VSS (also based on shared folder). It's risky and not efficient.

Explain to your boss how bad it is, invest in some 2-days SVN or GIT training, and start using real version control system while you still have your code in reasonable shape.

Answer 15

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.

Answer 16

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.

OK, the flashbacks are getting to me. Signing off. Good luck.

Answer 17

1. Get a stopwatch,
   • Count the time you spend in the spreadsheet just for synching up versions
   • Count the time you spend repairing broken versions
   • count the number of times people shout in the hallway "i'm editing main.c!, just to make sure nobody else is right now!".
   • count the number of complaints you get from customers because their bugfix contained other changes
   • count the time delay of release just because you were unable to synch up the versions
2. Make a powerpoint with this data, compare with how vcs would work.
3. Show management

Answer 18

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.

Answer 19

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!

Answer 20

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.

Answer 21

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 )

Answer 22

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.

Answer 23

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.

Answer 24

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

Answer 25

I have encontered this a lot...in small engineering/electronic companies where they do lot of embedded software/ hardware.

In these places SCM is not part of the electronics engineering culture. They usually have one engineer per project, who just needs to back up the latest release.

So branching/merging and even sharing code is considered irrelevent. Also, these companies are probably ISO9000, so the process, albiet weird, is probably documented.

In any case I/other developers have just started using SCM personally.

Answer 26

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:

1. Many of the "programmers" are script kiddies, and won't understand how to use it
2. Those who could learn, think it is a nuisance to use
3. These people are the old guard, comfortable with the network folders, so everyone should be
4. No one has time to set it up right, or learn how to use it
5. 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.

Answer 27

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.

Answer 28

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.

Answer 29

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.

Answer 30

It seems that you are some convinced, but someone in the organization is not empowering you to do it. As you can read from the other comments, you should do it.

You can find some information here: http://www.internetcontact.be/scm/?page_id=358

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.