How Common is Pair Programming in the Workplace?

Please take a day to install version control and teach everybody on the project to use it. It's not that hard. Personally I've not used Git, but I have set up and used other version control systems and they are not that hard to get working. Make sure you choose one that integrates with your development environment. This will make using it virtually seamless.

This will not be wasted time.

The time you will lose when someone overwrites or deletes some code will cost you much more.

If you don't have version control you will also spend an inordinate amount of time backing up your project and worrying about which version everyone has and which version is on the server etc.

If you need to convince your boss make an estimate of the time that it will take you to set up and monitor any non-version control solution and add in the cost of rewriting a few days lost work. Don't forget to add in the cost of manually merging edits from 3 developers working on the same source file and the extra cost of getting that merge wrong. Good version control gives you this for free

Then compare that to the cost of getting version control - nil (if you go open source) and setting it up - 3 man days.

Don't forget that an error later in the project is going to cost more than one early on. If you have to redo the entire project because of a mistake anyone can make this will cost far more than just the rewrite time, it might cost your boss the reputation of his firm.

First, let me say I completely sympathize with your position. It can be frustrating when you have a lack of understanding or a communication breakdown between different parts of the business. Having said that, I don't think you should try to keep them out. Instead you should show them the numbers about why this is a good idea. What facts do you have that justify unit testing is worth the effort you put into it? If you don't have any, then you should start to gather those figures, or show some research to back up your claims.

I have had to deal with similar scenarios myself and I answered this question on a similar topic. I also blogged about how I dealt with it here:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

In case you don't feel like link chasing, I'll repeat my summary from the related question:

To summarize, I compared our estimated hours against actual hours for the project and then compared our defect rate against other teams' defect rate. In our case these numbers compared favourably and there were no more concerns.

My conclusion based on this experience is:

...the best way to convince anyone that your approach to doing something is practical and pragmatic, is to do it and measure it against other approaches. People don’t care about dogma, or why you think something should be the best way. Only by showing people the numbers and measuring the effectiveness of your approach can you truly show that your practices are effective.

If your management team don't agree to investing what they see as an additional 150 hours on unit testing, perhaps you can convince them to invest in one small area of the product (or even agree to suck the hours up yourselves to provide some data). Do unit testing in that one area of the product then gather data about the defect rates in that area of the product and the cost to find and fix those defects compared to the defect rates in other areas of the product. Hopefully you'll gather some data to back up your case and this will be a non-issue for your next project.