8

I was just thinking about pair programming and one thought just crossed my mind that surely at some time two coders are not going to agree and it would kind of turn into a lengthy (maybe heated) discussion about an implementation of a paradigm or algorithm, etc. I expect these might be 'religious' wars over stuff? Does this happen?

Having never 'pair programmed' ever, is this something that occurs? Are there processes to stop lengthy discussions?

Improve this question
5
  • 5
    See my answer on StackOverflow
    – Sklivvz
    Apr 26, 2011 at 18:53
  • 1
    Some of my most productive work was based on conversations that were both lengthy discussion and heated. If these conversations actually are just "discussion" without any sort of "Eureka" moment then it can be a problem.
    – Ramhound
    Apr 26, 2011 at 18:56
  • A. Yes. At which point we call it team-building. ;-)
    – Drew
    Apr 28, 2011 at 9:11
  • Is there ANYTHING involving more than one person that doesn't sometimes turn into a lengthy unproductive discussion?
    – mjfgates
    Dec 3, 2011 at 6:09
  • @mjfgates Fair point! lol.
    – Gary Willoughby
    Dec 3, 2011 at 12:57

5 Answers 5

Reset to default
4

Tough discussions are sometimes a side-effect of pair programming, but this is not always a bad thing. As discussion about which approach to take means you are thinking about the code before you write it and you have more than one set of eyes on it.

Taken from: http://wundasworld.blogspot.com/2007/11/joy-of-pair-programming.html :

The ideal pairing situation requires both people to be expert developers. They need to be open to the other person's idea. And in this case (expert developers with good, strong opinions), its likely to bring pain.

However, "religious wars", if they are going to occur, are going to come up in a code review or elsewhere, if they don't come up pair programming. Avoiding unproductive discussion is something that has to be identified and avoided in any aspect of programming. The main way to avoid it pair programming, is to focus on getting the job completed, learning to choose solutions that meet multiple concerns, and learning when to give in when a choice is not worth the time it takes to argue about it.

Improve this answer
3

I haven't done a lot of pair programming, and generally reserve it for cases where I am really stuck or major design issues. These are precisely the situations where discussions show up, however. This is my experience:

  • Big discussions come up whether you are pair programming, or not. The difference is that pair programming brings them to the surface sooner, and gets more brains working on the issue right away. Because of this, I tend to seek out a programming partner when I hit code decisions that are important and difficult.
  • Heated discussions are generally not directed so much at each other as at the problem. When the problem is gone or made actionable (e.g., 'let's have a meeting to work this out'), bad feelings are gone and done with.
  • Heated discussions are signs that people care about the problem and want to find a solution. This kind of passion often leads to creativity and great solutions.
  • The benefits of pair programming not only outweigh the risk of frustration, but insulate against that risk. Success and good code can erase a lot of frustration or harsh feelings.
  • I see more heated discussions come up when a person is coding alone and goes in the wrong direction. At that point, the coder has a lot invested in the wrong direction, and it takes a lot more character to admit they need to redo a large chunk of work than it does to redo a few lines of code or an outline for the project.
  • 'Holy wars' are usually resolved by company or management preference, rational discussion about the pros and cons, or seniority. Holy wars that can't be resolved by one of these usually indicate that someone is a bad fit for the company, and the holy war topic would eventually have come up as a source of friction even without pair programming. An appeal to another authority can often help resolve these issues - e.g., let's have our boss / the client decide this.
Improve this answer
1

Typically when I pair program and a major discussion point comes up we try our best to set it aside for a separate discussion. There are going to be things that weren't considered when concocting the initial design, or differing opinions on how to implement something. It's best to just keep the programming session moving forward, as those sorts of discussion can be handled with more productive means than smack-dab in the middle of pair programming.

Improve this answer
0

The ones at the next cubicle over from mine seem to ALWAYS end up that way.

Improve this answer
0

In my experience, pair programming has been done as part of a general "extreme" approach, in which the short-term focus is on getting something up and running, with the understanding that refactoring is to be done later. Given that, the possible heated discussions tend to end up getting resolved with someone saying "Well, fine, we'll code it up your way for now and see how that goes; we can always change it later."

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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