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.

  • What do you mean by "labor work"? I'm unclear as to when coding wouldn't include problem solving. – David Arno Jan 8 '15 at 11:01
  • Something like write a program to import csv into database and mapping each field name from doucment which is a very easy task but you need lots of time to match each field and deal with lots of files. – Paiboon Panusbordee Jan 8 '15 at 11:07
  • Ah, sure for trvial one-off tasks there's no point in pair-programming; but there's also no point in treating it as a development project either: just get the script written, run it and throw it away. Planning, peer review, pair programming etc just add bureaucracy and wasted time in such cases. – David Arno Jan 8 '15 at 11:12
  • However, if it's a big enough task, even tedious stuff like matching up fields is speeded up through pairing as two pairs of eyes are likely to catch mistakes (which are all too easily made when the task is dull) much earlier and thus will save time in the long run. Working with someone else will also make the task less dull and thus the pair are likely to work faster than just one person on their own. – David Arno Jan 8 '15 at 11:13
  • 1
    This question is really more about a specific engineering practice (pair programming) than it is about project management. Pair programming can be on-topic as a project management control or framework process, but this question is too broad to be on-topic here. In addition, as currently written, it reads like a subjective opinion poll with many equally valid answers. Please consider editing the question, or flagging it for migration to Programmers instead. – Todd A. Jacobs Jan 8 '15 at 20:09

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.

  • While I agree with you, I don't think you've mentioned any negatives: eg that working closely together doesn't give either as much time for independent thought, and that close communication may mean both developers approaching a problem from the "same angle", reducing creativity or the chances of obscure things being noticed... in essence, they convince themselves and each other that their approach is effective, and by being able to confirm with each other, they're less criticial of their own contribution. This isn't always the case, or even often, but has happened in my experience. – Jon Story Jan 13 '15 at 12:36
  • @Jon: While those are definitely risks, not to mention risks around personality conflicts and the fact that though it's a small price, there is about a 15% overhead to it. However, I wasn't able to think of how to line that up types of projects to create a "bad case", so I excluded that from my answer only for brevity's sake, not to suggest those don't exist. – Daniel Jan 14 '15 at 18:50

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.