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

Answer 1

I haven't done the stats--and I suspect you'd have a hard time doing a statistically valid study--but keep in mind the ostensible objective of producing working, error-free code--not just quantity of code. A good pair should be able to create at least as much correct code as two programmers working separately.

Answer 2

We use this approach in our company, but only for the difficult tasks or when you're unsure about something someone else has worked on already which I believe works very well. It saves you getting stuck in a rut and being able to bounce ideas off people where necessary while still being able to work independently for most simple tasks.

I also believe it is more beneficial than a code review, which is something else we do where I work. It is often difficult to know fully what's going on when doing a code review without providing significant context, at which point you don't always have the time to think about all the in's and out's. Pair programming gives you that context from the start and allows you to spend more time thinking about edge cases that may or may not cause problems.

Answer 3

At work we use pair programming all the time. The trick is to know which tasks should be done in pair and which would be a "waste of time" if done by two developers. The rule of the thumb is that tasks that are more research oriented (i.e. POCs & spikes) should be done in pairs as well as development of new features (so that the knowledge will exist in more than one mind). Tasks that are more mundain such as CI server installation or replacement of the addon icons is done by a single developer. Another factor is the current availability of team members and the current tasks to be done at that iteration.

Answer 4

The first assumption one makes with pair programming is that a story card will cost twice a much to develop. The assumption is faulty. Here is why?

• Improved quality: A pair of active programmers working on the same story card will complete the card with less defects
• Improved productivity: a pair is less likely to be slowed down if not outright blocked when solving a problem. Furthermore, it is harder to take an email or web vacation when you are working with a partner ... you don't want to let the partner down. You will solve the problem with a cleaner design and less lines of code when working as a pair
• Eliminate silos of knowledge: With rotating pairs, you will learn application and domain business knowledge across the team. The team is less likely to be blocked because Sue when on vacation and no one else knows her code.
• Knowledge Transfer: Rotating pairs teach new skills (engineering and domain) to each other as they work together. The level of the team will rise for everyone and the knowledge propagates through the team.
• Team self selects: The team learns one anther's skills and will quickly weed out someone that is not performing.

From actual experience we have seen defect drop significantly. New team members can be added without slowing down the team (try that with a non-paired team). For a trial, one team estimated the work for a set of story cards as if six single developers would complete the code individually. The six developer were then told to pair. They completed the work on time with high quality. If you don't pair, you are spending to much time to deliver to little quality, you have no way to scale and you have too many silos of expertise.

In a second example, we estimated to complete the work in the time requested we would need to take a team from 4 pairs to 7 pairs. We gave ourselves 1 month to on board the new pairs. We paired a new developer with an experienced developer and rotated the pairs across story cards. The team hit all deliverables with quality in the time planned. Without pairing one could not have added 6 developers to a team of 8 developers and hit the mark!

Bottom line, you will save money with pairing. You will take about the same time, delivery with higher quality, improve the teams performance, skills and knowledge and weed out the dead wood. Your savings will come with sustainable pace and significantly fewer defects in the way to slow the team down.

Answer 5

It's hard to say - I've spent a lot of time working in a force-paired environment and also in a pairing-optional environment. The highest quality code I've seen is not in the paired environment. That probably has more to do with the caliber and discipline of the individual developers. Sometimes you'll get your money's worth from pairing, especially where some of the coders are not top-tier. But if all the coders are experienced, well-disciplined coders, you're just wasting your money if they're pairing all the time.

One type of experience that I've had multiple times that has a huge impact on my coding discipline and the quality of product I produce is this: carrying a pager. When I have to support a system for which I code, it changes how I code. That is, I code in such a way as to keep that pager from going off. The result is a better quality product, and typically better code quality, too. The coders I've seen that have never carried a pager produce code that's more fragile. It's not something that they can even understand and improve upon until they've been on support.

Answer 6

It does not mean double the cost if it takes less than 1/2 the time it would have taken with one dev. I think on difficult or low-level tasks this would be helpful. I find that it's worth it because you've got someone to say "no, don't do THAT!" long before it ends up in production code where it will REALLY cost you time and money.

I've written operating systems and things of that nature where it was invaluable that someone was sitting next to me to double check my logic.