Last week I found myself trying to explain to my management that team development is better than individuals programming alone. Unfortunately, I didn't have any hard facts to back this claim up.The managements issue is that 2 developers on a project equals 2 times the cost.
What advantages have you found in working as a team? Articles,blogs,project plans,metrics, etc will help whenever I go back and explain. Thanks in advance
My experience is that many hands make light work. Yes, more developers will cost more money but that money is not a loss - it is an investment against the time that will be gained by more people working at once.
This may sound trite, but you will need to demonstrate the value for the extra cost.
It goes something like with 2 developers the code is done in less time (not half), however with 2 developers the code is also of higher quality because there are 2 eyes reviewing it and you have additional coverage in case something unexpected happens like an illness or one of you gets stumped. As a team you're also able to tackle a larger problem.
You may also be face a pure matter of cashflow, money in does need to exceed money out for a business to make money.
I've come across an NY Times article and a blog post in the past week supporting pair programming. I think it is fair to say that these concepts apply to team development as well. I wish these were objective studies supporting team development/pair programming, but objective studies on pair programming still seem controversial at best.
In general both articles say the same thing, by putting a responsible team together you reduce thrashing, encourage communication between team members, and increase accountability. Take a look...
http://www.nytimes.com/2009/09/20/jobs/20pre.html?%5Fr=2# (Sorry, but this one is behind a registration wall.)
http://agilesoftwaredevelopment.com/blog/mendelt/dirty-secret-pair-programming
Have you considered that there might be a business reason to it?
You should not force $ / month to go up on something unless you are sure the source of those $ will be able to keep up with it (and will then benefit from it quickly). Keeping the whole business / or the client's of the project business healthy should be on the top of the list, forcing their budget can get everyone in an ugly spot in the future.
If that's not the case, you need to focus on time to market and concrete value they will get out of it. If there is no clear value to be generated from it, its likely there are bigger problems that need to be solved first.
One of the best ways you can backup your arguments for implementing pair programming is to use data that is local to your business, so you need to ask, 'Why do companies pair program?'
In my experience their are two main reasons, the first is that bugs cost more to fix the later they are found. If I find a bug when I'm writing code I can fix it straight away. If I find it in acceptance testing, then I'll need to isolate where the problem has occurred and then spend serious time debugging to find the reason for why it has occurred. The advantage that you get from pair programming is that you have twice the chance of seeing these bugs, especially if you have a slight knowledge difference between the programmers - it prompts questions about the way things are being done and thus you find more bugs.
The second reason (and only really useful if you are developing somewhere where knowledge isn't recorded well) is that it acts as a risk mitigation tool - if you have 2 people who know how a critical code area works, if one of them gets sick then you still have the other to fall back on.
Whilst I would recommend that the best way to sell to most managers (especially non-technical managers) is to rely on localise data (because they have to trust the data they mined) some good peer-reviewed papers on this are:
http://jacques.dsc.ufcg.edu.br/cursos/map/recursos/XPSardinia.pdf (the abstract shows both cost increases and output increases, which is handy because many managers can't be bothered looking past the abstract)
http://www2.computer.org/portal/web/csdl/doi/10.1109/METRIC.2003.1232465 (which is hidden behind a subscription wall) which says it can be good and it can be bad
The biggest issue is the most of these studies are performed on students, and whilst the results may still hold in the corporate development world, many managers will baulk at this comparison.
Good Luck!
Don't forget the No.19 bus argument. If we have a lone developer working on a piece of software then the project is exceptionally vulnerable to that person dropping dead, falling seriously ill or just handing in their notice.
If we know anything about IT it is this: a single point of failure is A Bad Thing.