A programação de pares se transforma em uma longa discussão improdutiva?

Eu estava pensando em programação em pares e um pensamento passou pela minha cabeça: certamente, em algum momento, dois codificadores não vão concordar e isso meio que se transformaria em uma longa discussão (talvez acalorada) sobre a implementação de um paradigma ou algoritmo, etc. Espero que possam ser guerras "religiosas" por causa de coisas? Isso acontece?

Nunca tendo 'par programado' nunca, isso é algo que ocorre? Existem processos para interromper longas discussões?

Discussões difíceis às vezes são um efeito colateral da programação em pares, mas isso nem sempre é uma coisa ruim. Como a discussão sobre qual abordagem adotar significa que você está pensando no código antes de escrevê-lo e tem mais de um par de olhos nele.

Retirado de: http://wundasworld.blogspot.com/2007/11/joy-of-pair-programming.html :

A situação ideal de emparelhamento requer que ambas as pessoas sejam desenvolvedores especialistas. Eles precisam estar abertos à ideia da outra pessoa. E, neste caso (desenvolvedores especializados com opiniões boas e fortes), é provável que traga dor.

No entanto, "guerras religiosas", se ocorrerem, aparecerão em uma revisão de código ou em outro lugar, se não surgirem programas em pares. Evitar discussões improdutivas é algo que deve ser identificado e evitado em qualquer aspecto da programação. A principal maneira de evitá-lo emparelhar a programação é se concentrar em concluir o trabalho, aprender a escolher soluções que atendam a várias preocupações e aprender a desistir quando uma escolha não vale o tempo necessário para discutir sobre ela.

Eu não fiz muita programação em pares e geralmente a reservo para casos em que estou realmente paralisado ou com problemas de design importantes. Essas são precisamente as situações em que as discussões aparecem, no entanto. Esta é a minha experiência:

• Surgem grandes discussões, independentemente de você ser uma programação em pares ou não. A diferença é que a programação em pares os traz à tona mais cedo e coloca mais cérebro trabalhando na questão imediatamente. Por causa disso, costumo procurar um parceiro de programação quando tomo decisões importantes e difíceis.
• Discussões acaloradas geralmente não são dirigidas tanto uma à outra como ao problema. Quando o problema desaparece ou se torna passível de ação (por exemplo, "vamos ter uma reunião para resolver isso"), os sentimentos ruins acabam e acabam.
• Discussões acaloradas são sinais de que as pessoas se preocupam com o problema e querem encontrar uma solução. Esse tipo de paixão geralmente leva à criatividade e a grandes soluções.
• Os benefícios da programação em pares não apenas superam o risco de frustração, mas também isolam esse risco. Sucesso e bom código podem apagar muita frustração ou sentimentos duros.
• Vejo discussões mais acaloradas quando uma pessoa está codificando sozinha e segue na direção errada. Nesse ponto, o codificador investiu muito na direção errada e é necessário muito mais caracteres para admitir que eles precisam refazer uma grande parte do trabalho do que refazer algumas linhas de código ou um esboço do projeto.
• As 'guerras sagradas' geralmente são resolvidas pela preferência da empresa ou da administração, discussão racional sobre os prós e os contras ou antiguidade. As guerras santas que não podem ser resolvidas por uma delas geralmente indicam que alguém se encaixa mal na empresa, e o tópico da guerra sagrada acabaria surgindo como fonte de atrito mesmo sem a programação de pares. Um apelo a outra autoridade geralmente pode ajudar a resolver esses problemas - por exemplo, vamos pedir ao nosso chefe / cliente que decida isso.

Normalmente, quando eu emparelho o programa e surge um grande ponto de discussão, tentamos o nosso melhor para separá-lo para uma discussão separada. Haverá coisas que não foram consideradas ao inventar o design inicial ou opiniões divergentes sobre como implementar algo. É melhor manter a sessão de programação em andamento, pois esse tipo de discussão pode ser tratado com meios mais produtivos do que o smack-dab no meio da programação em pares.

Os do cubículo ao lado do meu parecem SEMPRE acabar assim.

Na minha experiência, a programação em pares foi feita como parte de uma abordagem geral "extrema", na qual o foco de curto prazo é colocar algo em funcionamento, com o entendimento de que a refatoração deve ser feita posteriormente. Dado isso, as possíveis discussões acaloradas tendem a ser resolvidas com alguém dizendo: "Bem, tudo bem, vamos codificar o seu caminho por enquanto e ver como isso acontece; sempre podemos mudar isso mais tarde".