¿Por qué muchos programadores se oponen a la programación en pareja?

He programado muchos pares, pero solo comencé a hacerlo después de una larga carrera. He estado programando durante 34 años en total, pero solo comencé la programación de pares hace unos 6 años. No pasó mucho tiempo para darse cuenta de que uno de los secretos sobre la programación de pares es que un par de desarrolladores tienden a centrarse más en la tarea en cuestión. Mientras que un solo desarrollador puede salir fácilmente en una expedición personal para explorar su tecnología favorita. Digamos que parte de la tarea es usar una base de datos SQL y al desarrollador le encanta SQL, ¿adivina qué? El desarrollador, por su cuenta, podría pasar mucho más tiempo del necesario jugando con SQL, puliendo su código, leyendo sobre SQL y, en general, jugando y experimentando y probando cosas. Si está en un par, este tipo de pérdida de tiempo aún puede continuar, pero en menor medida. Efectivamente, el par de programación tiene el doble de conciencia acerca de hacer la tarea a mano. Diría que esta doble conciencia es la mejor parte de la programación de pares, pero por alguna razón nadie parece escribir sobre eso. ¡Así que AFAIK esta es la primera vez! 🙂

Entonces, si está decidido a querer tomarse su propio tiempo dulce para cualquier tarea en particular, entonces diría que esta es la razón # 1 para oponerse a la programación de pares. # 2 es probablemente más un aspecto social. No hay nada peor que programar en pareja con alguien que está ‘conduciendo’ que no quiere o no está interesado en aprender a hablar en voz alta como está pensando. Si alguien está pensando y no hablando, entonces no puede seguirlo y no está en la misma página, no está trabajando juntos, y se sentirá más como una mano derecha que ha sido cortada. Obviamente, diferentes desarrolladores dominarán el arte de pensar en voz alta en diferentes marcos de tiempo y en diferentes grados. Pero, básicamente, si eres tímido y simplemente no quieres hacerlo, entonces apestarás en la programación de pares … o al menos será un asco para el emparejamiento de desarrolladores contigo.

Yo diría que la razón # 3 para oponerse a la programación de pares sería la defensa religiosa de varias tecnologías. Si un fanático de vim y un fanático del eclipse comienzan a emparejarse y no pueden “ superarse ” a sí mismos y a su solución personal de tecnología, entonces las chispas de programación de pares obviamente comenzarán a volar … si alguno de ellos comienza a emparejar el programa.

Estas serían las 3 razones principales que he observado. Curiosamente, también son las 3 razones principales por las que estoy a favor de la programación en pareja 🙂 # 1 Es genial tener a todo el equipo analizando las tareas de mayor prioridad sin distraerse. # 2 Cuando las parejas experimentadas aprenden a pensar en voz alta, es sorprendente lo mucho más productivos que pueden ser dos cerebros para resolver problemas y no cometer errores que un cerebro. ¡Y la programación de pares n. ° 3 es la forma ideal de aprender y adoptar las nuevas tecnologías sobre la marcha!

Porque Pair Programming ™, tal como lo imponen los gerentes despistados que buscan palabras de moda ágiles, es una basura completa sin adulterar. Es otro caso más de “X es bueno, por lo tanto, X llevado al extremo y obligado por las reglas de la compañía debe ser mejor” (compárese con TDD).

Hay una y solo una situación en la que la programación de pares tiene sentido: la transferencia de conocimiento de la persona con más conocimientos a la persona con menos conocimientos. Aparte de eso, acaba de desperdiciar el doble del poder de desarrollo para obtener, en el mejor de los casos, un beneficio de + 20%. Déjame explicarte explícitamente:

Si ambos desarrolladores en el par tienen el mismo nivel de habilidad, en cualquier momento dado uno de ellos seguramente está perdiendo el tiempo por completo.

No se equivoquen, donde estoy trabajando, somos un equipo. Si hay un problema difícil de resolver, nos reuniremos y presentaremos algunas ideas hasta que una de ellas se mantenga. Regularmente (casi a diario) revisamos el código del otro, especialmente cuando el trabajo todavía está en progreso (como diría Alan Mellor, “La revisión del código en las solicitudes de extracción suele ser demasiado tarde”). Lo que no hacemos es que la mitad del equipo se siente sobre sus culos y mueva sus pulgares, mientras que la otra mitad está escribiendo un código de rutina del que nadie se preocupa.

Estoy tan entusiasmado con la programación de pares como David Gilmour estaría emocionado de que alguien más tocara las cuerdas mientras solo estaba tocando los dedos, y luego cambiando de lugar de vez en cuando. Es casi tan eficiente como tener dos motores de combustión interna separados en un automóvil.


Agregado el 18 de junio de 2017: se me hizo notar que fui innecesariamente grosero con Kent Beck en mi última oración, así que lo eliminé. Es un buen desarrollador de software, y es probable que su idea de programación extrema se ajustara a sus circunstancias en el momento del (in?) Famoso proyecto Chrysler. Sin embargo, estoy totalmente en desacuerdo con su afirmación de que es la forma correcta, y lo consideraría como un buen ejemplo de sesgo de supervivencia (en otras palabras, las personas que intentaron lo mismo y fallaron por completo no continuaron escribiendo o editando decenas de libros al respecto).

De hecho, no creo que haya una solución única para el desarrollo de software. Los equipos, clientes, productos y herramientas son diferentes de un caso a otro, y el proceso debe ajustarse en consecuencia. La programación de pares en particular solo funciona para circunstancias específicas, que no se encuentran con mucha frecuencia, sin embargo, algunas personas lo tratan como un evangelio porque funcionó esa vez. Es bastante irónico, realmente, que la programación extrema, un conjunto de conceptos que giran en torno a la flexibilidad, se haya vuelto tan calcificada y rígida en la mente de muchas personas.