¿La programación en pareja se convierte en una larga discusión improductiva?

Estaba pensando en la programación de pares y un pensamiento me pasó por la mente que seguramente en algún momento dos codificadores no estarán de acuerdo y se convertiría en una discusión larga (quizás acalorada) sobre la implementación de un paradigma o algoritmo, etc. ¿Espero que estas sean guerras "religiosas" por cosas? ¿Esto pasa?

Como nunca se ha 'emparejado', ¿es algo que ocurre? ¿Hay procesos para detener largas discusiones?

Las discusiones difíciles a veces son un efecto secundario de la programación de pares, pero esto no siempre es algo malo. Como discusión sobre qué enfoque tomar significa que está pensando en el código antes de escribirlo y tiene más de un par de ojos en él.

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

La situación ideal de emparejamiento requiere que ambas personas sean desarrolladores expertos. Deben estar abiertos a la idea de la otra persona. Y en este caso (desarrolladores expertos con buenas y fuertes opiniones), es probable que traiga dolor.

Sin embargo, las "guerras religiosas", si van a ocurrir, aparecerán en una revisión de código o en otra parte, si no surgen programación de pares. Evitar discusiones improductivas es algo que debe identificarse y evitarse en cualquier aspecto de la programación. La forma principal de evitar la programación de pares es concentrarse en completar el trabajo, aprender a elegir soluciones que satisfagan múltiples preocupaciones y aprender cuándo ceder cuando una opción no vale la pena el tiempo necesario para discutir sobre ello.

No he hecho una gran cantidad de programación de pares, y generalmente la reservo para casos en los que estoy realmente atascado o tengo problemas de diseño importantes. Sin embargo, estas son precisamente las situaciones en las que aparecen discusiones. Esta es mi experiencia:

• Surgen grandes discusiones, ya sea que esté programando en pareja o no. La diferencia es que la programación de pares los lleva a la superficie antes y consigue que más cerebros trabajen en el tema de inmediato. Debido a esto, tiendo a buscar un socio de programación cuando tomo decisiones de código que son importantes y difíciles.
• Las discusiones acaloradas generalmente no se dirigen tanto el uno al otro como el problema. Cuando el problema desaparece o se hace viable (por ejemplo, "tengamos una reunión para resolver esto"), los malos sentimientos desaparecen y se resuelven.
• Las discusiones acaloradas son signos de que las personas se preocupan por el problema y desean encontrar una solución. Este tipo de pasión a menudo conduce a la creatividad y a grandes soluciones.
• Los beneficios de la programación de pares no solo superan el riesgo de frustración, sino que aíslan contra ese riesgo. El éxito y el buen código pueden borrar mucha frustración o sentimientos duros.
• Veo más discusiones acaloradas cuando una persona codifica sola y va en la dirección equivocada. En ese momento, el codificador ha invertido mucho en la dirección equivocada, y se necesita mucho más carácter para admitir que necesitan rehacer una gran parte del trabajo que para rehacer algunas líneas de código o un esquema para el proyecto.
• Las 'guerras santas' generalmente se resuelven por preferencia de la empresa o la gerencia, discusión racional sobre los pros y los contras, o antigüedad. Las guerras santas que no pueden ser resueltas por uno de estos generalmente indican que alguien encaja mal en la compañía, y el tema de la guerra santa podría haber surgido como una fuente de fricción, incluso sin la programación de pares. Una apelación a otra autoridad a menudo puede ayudar a resolver estos problemas; por ejemplo, hagamos que nuestro jefe / cliente decida esto.

Por lo general, cuando emparejo el programa y surge un importante punto de discusión, hacemos todo lo posible para dejarlo de lado para una discusión por separado. Habrá cosas que no se consideraron al inventar el diseño inicial, o diferentes opiniones sobre cómo implementar algo. Es mejor que la sesión de programación siga avanzando, ya que ese tipo de discusión puede manejarse con medios más productivos que un golpe directo en medio de la programación de pares.

Los que están en el próximo cubículo del mío SIEMPRE terminan así.

En mi experiencia, la programación de pares se ha realizado como parte de un enfoque general "extremo", en el que el enfoque a corto plazo es poner en marcha algo, con el entendimiento de que la refactorización se realizará más adelante. Dado eso, las posibles discusiones acaloradas tienden a resolverse con alguien que dice "Bueno, está bien, lo codificaremos por ahora y veremos cómo funciona; siempre podemos cambiarlo más adelante".