I know pair programming has lots of good point to use. However, I don't think it will be a silver bullet in every situation. Is there an example of bad case to use pair programming or bad situation in some team arrangement? Ex. Too much waste time when it's labor work that do not need much problem solving.
closed as off-topic by Todd A. Jacobs♦, Alex Leonov, Mark C. Wallace, Aziz Shaikh, Willl Jan 13 '15 at 10:54
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Software engineering questions are off-topic here, but can be asked on Programmers Stack Exchange." – Todd A. Jacobs, Alex Leonov, Mark C. Wallace, Aziz Shaikh, Willl
There are real challenges when doing paired programming, but I don't think there are usually "bad projects" to do it on. The classic argument against it is the work where you "know what you have to do and you're just typing it in", or what you're calling labor work, but I think those are so few and far between that they're hardly worth addressing.
When I've had this conversation in the past, the notion is that the developer comes up with a plan of attack, then types it in. My experience would tell me that is wrong. When developing, I create a high-level planned approach, but I don't figure out all of my LINQ statements and other details up-front. Those things come as I'm entering them. Even as an experienced developer, there can be benefit in paired-programming that sort of work.
Another common example I've heard is writing transforms. The assumption again is that you're just mapping one field to another. Again, I've rarely found this to be true. There are often data type conversions, error handling, and logic decisions that occur in that code.
In general, when people say they are doing a lot of mindless work, I've found that they are either a) incorrect that it is mindless or b) doing the work wrong. In both cases, paired programming can help.
You might find this report interesting: The Effectiveness of Pair Programming: A Meta-Analysis
It basically describes the trade-offs of pair programming, that is, when it's more or less conducive to increased productivity and reduction of mistakes.
From personal experience, I'd say that pair programming offers excellent benefits in situations where two high quality developers, with good communication skills, get to work together. The code is automatically peer-reviewed as it's written, unit tests are more likely to get written and refactoring occurs more often as the temptation to cut corners and accrue technical debt is reduced.
However, the key here is "two high quality developers, with good communication skills". In situations where a developer finds it hard to "think aloud", doesn't have good communication skills or needs time to understand existing code or to design new code, then pair programming doesn't work so well.