Pair programming means double cost per developer. Is it worth that money? [closed]

Answer 1

With pair programming, you combine:

• Higher quality code
• Better distribution of inner knowledge
• More team spirit

You won't get that much return on investment easier than that.

Then again, you shouldn't use it for all tasks.

Answer 2

The premise is that your productivity more than doubles. Part of the gain is realized right away (e.g., before code is checked in) and part is realized further on, when there are fewer bugs and failures.

When I teach students with two semesters' experience, for most pairs their productivity more than doubles because they ask each other questions and they learn and finish faster. But it's not universally true; a badly matched pair can take longer and do worse than the more skilled half.

Answer 3

The sooner a bug/defect is found the cheaper it is to fix, so using the money to hire more qa people vs another developers, is going to cost you more time/money because of how many trips from DEV to QA.

Having said this, pair programing don't work with everyone, some developers don't pair well, they distract each other, spend all their time fighting, etc.

If you have developers that can pair program, it can be more then beneficial in the long run when you add in more maintainable code, lower defects so less time in QA, and most importantly if one of the developers get hit by a bus, you don't have to wait for someone to come up to speed on a project before any more work can be done on it.

If your developers can't pair program don't force them into it, all you're going to do is waste time and money.

Answer 4

Quality management experience from other many industries teaches us that defect prevention is cheaper in the long run than defect detection (also known as QA) and subsequent fixing.

They also learned that the long run ranges in most cases from 1 to 2 years, which means that your investment pays off after that. Considering that investments on that scale are usually expected to reach a break even after 4 years, this is pretty good!

The problem is that it took the other industries several decades to accumulate enough data for being able to prove that this is the case for them. You can easily find data to support their conclusion and draw a conclusion for software in analogy to that, but as of today, there is no proof for the software business.

That being said, I believe that the analogous conclusion is valid: A pair of developers and one tester are more productive than one developer and two testers.

If you have problems justifying two expensive developers sitting in front of one computer to the managament, there are many other things that help with defect prevention, but are not as visible (and therefore irritating) to the management.

Answer 5

It's not a black and white thing or a silver bullet of any kind, the concept of pair programming.

Pair programming is generally extremely efficient for various reasons, but done right it's also very exhausting (in my opinion any way) - meaning a good pair might pair program a few hours a day at most. This should be encouraged, of course, but not mandated and especially not mandated at 100% time because that seems hard to manage (with sustained efficiency and no beer anyway).

So, pair programming is just one way of approaching a problem, and I find it hard to look at it from the question's perspective. It's not like you need to hire twice as many developers for this. It's like wondering if it's worth hiring a message boy/girl to have two employees in the same department talk to each other... when the obvious solution is to have them talk to each other directly without an additional messenger.

Answer 6

No way man! in the company i'm working we practice a lot of pair-programming! it gets things done really fast and really efficiently! just make a try! you will valuate it later!