¿Cuáles son las posibles desventajas de la programación de pares? [cerrado]

La programación de pares es bastante famosa hoy en día.

Tiene varias ventajas como:

1. Programas con menos errores.
2. El costo de mantenimiento posterior a la producción es mucho menor.
3. Las prácticas establecidas son desafiadas, lo que resulta en la aparición de nuevas ideas.
4. Los programadores aprenden unos de otros.
5. Los programadores desarrollan habilidades blandas.

¿Pero cuáles son las desventajas de la programación de pares?

Aunque la programación de pares ha ganado una reputación considerable, también tiene varias dificultades.

Algunos de ellos son los siguientes:

1. En la programación de pares no puede sentarse y autoevaluar su propio código.
2. Uno de los dos puede dejar de participar activamente.
3. El conductor necesita "programar en voz alta". La programación silenciosa reduce el beneficio.
4. Cuesta más horas hombre producir las mismas características. Se debe mantener el equilibrio entre la calidad del código y el aumento del costo de codificación.
5. Un fenómeno de "mirar al maestro" puede surgir cuando un programador experimentado y un novato se emparejan. El miembro novato puede convertirse en el observador con el miembro experimentado completando la mayoría de la codificación.
6. Cuando dos usuarios experimentados se emparejan, puede surgir un fenómeno de "ego del desarrollador", con cada miembro tratando de impulsar sus propias ideas.

Intenté programar en parejas varias veces, incluso en una organización que (brevemente) consideró implementarlo como un proceso obligatorio para todos los ingenieros (se puede adivinar qué tan bien surgió esa idea). Personalmente, lo odiaba.

Las razones que enumero a continuación son solo mis experiencias subjetivas, y no puedo 'medir' su impacto en términos concretos. Pero aquí son todos iguales:

1 - Tener un 'navegador' y un 'conductor' solo ayuda si el primero es vocal y el segundo escuchará.

Todos hemos conocido desarrolladores que son tercos, celosos de alguna preocupación teórica o patológicamente incapaces, psicológicamente, de 'tirar' el trabajo viejo cuando alguien sugiere un problema con él. Y todos conocemos a personas demasiado tímidas o confusas para plantear inquietudes o sugerir casos esquimales.

Cuando este tipo de desarrolladores están emparejados, el navegador rápidamente toma un rol pasivo, y lo que termina es la programación única con una revisión automática de código. Este es un monumental desperdicio de recursos.

2 - El emparejamiento impide la creatividad.

Contrariamente a lo que se sentía anteriormente sobre el valor de la "lluvia de ideas grupal", el consenso en estos días es que el trabajo de conocimiento creativo requiere independencia y autonomía . Cuando trabajas solo, puedes hackear rápidamente alguna idea loca para ver si es realmente factible. Puedes armar sin palabras algún prototipo extraño, y si fallas, no importa, porque nadie lo sabe .

Compare eso con el emparejamiento: cuando quiero probar un nuevo concepto, tengo que convencer a mi compañero, hablar sobre la implementación, paso a paso, y esperar que no me juzguen si falla. Ese tipo de ambiente es tóxico para crear nuevas ideas.

3 - Diseño de mínimo común denominador.

Cuando un par no puede generar nuevas ideas, como se indicó anteriormente, o cuando los individuos no pueden ponerse de acuerdo sobre algún principio fundamental de cómo se debe diseñar una característica, lo que sale es un diseño confuso que intenta comprometer y no satisface a nadie.

Si emparejas a un desarrollador que construye abstracciones de programación funcionales maravillosas, elocuentes y hacia el cielo con un fenómeno de rendimiento rápido y sucio, el código que producirán juntos generalmente no será terriblemente elegante ni particularmente rápido.

4 - Falta de autonomía y transparencia violenta.

La transparencia violenta es una frase que saqué de una polémica moderadamente famosa (y bastante controvertida) contra la metodología Scrum. Describe la forma en que algunas organizaciones infantilizan a los desarrolladores y los tratan con la sospecha normalmente reservada para los trabajadores no profesionales.

Independientemente de lo que piense acerca de los "daños" de hacer que el trabajo de los desarrolladores sea completamente transparente (y puede que no esté de acuerdo en que es realmente un daño), muchas personas valoran su autonomía y su capacidad para trabajar solos, confiando en hacer lo correcto. Es una necesidad psicológica importante, y obligar a los desarrolladores a emparejarse (como he visto suceder en al menos una tienda) dejará a los empleados consternados, molestos y alienados.

5 - Algunos desarrolladores simplemente no juegan muy bien en parejas.

Algunas personas no pueden o no pueden comportarse adecuadamente en un entorno emparejado. Pueden tener mala higiene, malos hábitos de trabajo, una personalidad abrasiva, una manera "ruidosa" e "intensa", o una gran cantidad de otros atributos que los hacen buenos trabajadores individuales, pero pobres programadores de parejas.

¿Puedes resolver esto? Realmente no. Cambiar el comportamiento personal es difícil. Una tienda de programación de pares debe tener mucho cuidado con la contratación e invertir mucho tiempo para ver cómo alguien trabaja y si podrán trabajar bien con sus compañeros. Sin embargo, discriminar más a la personalidad significa que la contratación llevará más tiempo a menos que afloje sus estándares de habilidades y experiencia.

Depende de su situación o perspectiva.

La programación en pareja es buena para la organización. ¿Pero es bueno para el individuo?

Después de todo, es un método de ahorro de costos (retroalimentación temprana) y productividad; No se trata de usted, sino del proyecto, producto, empresa ($$).

Aunque puede tener beneficios personales, no son la razón o el fin de ninguna metodología de desarrollo. La programación de pares (a tiempo completo), por ejemplo, también evita que te relajes, navegues, etc., debes justificar tus pausas ante tu pareja.

Su compañero (rotativo) será la mejor cámara de vigilancia: la intensidad del trabajo aumenta.

O, al distribuir el conocimiento, el individuo se vuelve menos riesgoso para la empresa (por ejemplo, no puede abandonar la empresa con el conocimiento esencial) y tiene menos "fichas de negociación".

Estoy seguro de que encontrará más puntos al leer artículos afirmativos de manera más crítica desde SU situación / punto de vista real en la empresa en lugar de desde la perspectiva de su gerente.

Casi todas las metodologías están escritas desde la perspectiva del gerente.

1. De repente, ahora tiene que decirle a alguien cuándo quiere ir al baño o tomar un café. Al menos no hay necesidad de pedir permiso.

2. Tienes que hacer frente a las normas de higiene de la otra persona.

Además de otras respuestas:

1. Muchas empresas para las que he trabajado emiten sus programadores con computadoras portátiles (basadas en el sitio de los clientes; es más fácil mantener el equipo seguro si se lo llevan a casa después del trabajo, poder hacer un trabajo extraño desde casa en VPN en un apuro, etc.) Muchos años Hace ya tuve problemas para ver en la pantalla de la computadora portátil de otra persona (el "conductor") desde la perspectiva de navegación del hombro: la edad no mejorará esto (y algunas pantallas se vuelven difíciles de leer fuera del ángulo de visión ideal en cualquier caso).

   Por lo tanto, los programadores de pares necesitarán pantallas suficientemente grandes, lo que aumentará el costo del hardware y limitará la adaptabilidad a la ubicación. Puede que no sea un problema para algunos, en otros casos será un problema.

2. También descubrí que las diferencias en las preferencias de higiene personal (como fumar, comer y beber), así como los enfrentamientos de personalidad, pueden obstaculizar la productividad. Es bastante fácil decirle a dos programadores que "aguanten y se lleven bien", a menudo esto hará que las personas mantengan la boca cerrada y se saboteen en silencio a través de acciones pasivas-agresivas para desahogar sus resentimientos.
3. Ruido. Yo, por mi parte, me gusta un ambiente de trabajo tranquilo. No puedo imaginar la charla constante de algunos grupos de programadores de pares (ya que necesita hablar para comunicarse). Incluso la música vocal en mis auriculares tiende a interferir con mi concentración (instrumentos insípidos para escuchar en la oficina ...). Supongo que esto puede mitigarse alejándose de la omnipresente oficina de planta abierta a salas de oficina dedicadas para 2 personas, pero eso aumentará los costos nuevamente.

Anécdotas para tu diversión:

• Un empleador anterior una vez consiguió un contratista de otro país (todo para permanecer en el anonimato para proteger al culpable). El empleador proporcionó alojamiento pero no transporte. Como dicho contratista vivía en mi ruta al trabajo, me ofrecí voluntariamente para recogerlo y dejarlo nuevamente. Digamos que su higiene personal no estaba en el mismo nivel de lo que estoy acostumbrado, y también fumaba mucho ("¡el más fuerte!") Mientras que yo no. En nuestro viaje de 15 minutos a la oficina, mantuve mi ventana bajada, incluso en invierno, lo que no impidió que mi auto oliera como una habitación de fumadores rancia después de los 3 meses del colega (no, él no fumaba en el auto , pero lo hizo mientras me esperaba).
• Tampoco hicimos programación de pares, sino que nos sentamos uno al lado del otro en una mesa de conferencias (por un tiempo). Después de aproximadamente un mes, había un bonito anillo marrón en la madera sintética de la mesa alrededor de la posición de la mano del ratón del colega. En ese momento, obtuve un escritorio abierto justo al lado del área de planta abierta del centro de llamadas, que prefería (con la ayuda de mis auriculares).
• Luego está la bebida ubicua de la oficina: café. Aunque lo bebo, puedo llevarme bien y no bebo tan a menudo como otros compañeros de trabajo. Las respiraciones a corta distancia pueden ser bastante desagradables, similar al olor de la taza vacía olvidada. Llamemos a la fragancia "bochornosa" ...

Creo que la programación de pares falla por razones sociales y prácticas. Esencialmente, le está pidiendo a una persona que trabaje bajo vigilancia constante y a la otra que no haga nada más que hacer agujeros.

Lo que inevitablemente sucede después de un tiempo es que la pareja se separó para 'revisar correos electrónicos' o 'usted continúa revisando ese problema en vivo', etc.

En lugar de mejorar la salida del código, el volumen disminuye. Tanto por razones prácticas 'Necesito ir al almuerzo / reunión fuera de sincronía con usted' y social 'Solo esperaré a que Bob termine lo que está haciendo antes de preguntar acerca de emparejarse nuevamente, no quiero que me vean molestando'

En cuanto a las ventajas alardeadas, hay muchas prácticas comunes que las logran de manera más simple y efectiva

Decirle a dos desarrolladores senior que hagan una "programación dolorosa" si están seguros de que uno puede hacer el trabajo es la mayor desventaja.