Pair Programming: cuenta con más de un cerebro

En una nueva era en la que el trabajo remoto parece ser la forma más sostenible de trabajar, hay herramientas que han alcanzado un gran potencial. Las herramientas de desarrollo de software colaborativas han aumentado en número y calidad. Parece que pair-programing ha venido para quedarse.

Por lo general, la programación ha sido vista como una actividad individual. La personalidad de los programadores ha sido generalizada y popularizada como personas solitarias con habilidades de comunicación limitadas y nerds.

La característica colaborativa en el desarrollo de software ha sido subestimada. La peor parte de esta narrativa ha permeado en las empresas: los informáticos son personas incómodas que apenas hablan de cosas comprensibles.

Lejos de esta realidad, desde la perspectiva de la ingeniería de software ágil, cada vez más organizaciones creen en los equipos de alto rendimiento. Los equipos de alto rendimiento no están formados por personas extraordinarias. De hecho, lo que los hace realmente buenos es cómo se comunican y cuán efectivamente trabajan juntos. Es por eso que en este artículo expondremos una de nuestras herramientas favoritas: el pair-programming.

A pesar de que no se trata de cómo funciona el pair-programming, este artículo expone por qué el pair-programming es una técnica tremendamente enriquecedora y por qué no debe ser subestimada por muchos gerentes o líderes de nivel ejecutivo.

Tener más de un cerebro

El pair-programming es un concepto simple, dos desarrolladores trabajan juntos en un mismo ordenador. Detrás de estos conceptos simples, hay un esfuerzo colaborativo que implica mucha comunicación y enfoque.

El pair-programming es un subconjunto de una metodología llamada Extreme Programming (XP). XP es un conjunto de prácticas de desarrollo de software centradas en el ser humano que se crearon para producir software de alta calidad y adaptarse a requisitos cambiantes y en evolución.

El pair-programming no se trata de detectar errores tipográficos que un linter o compilador no puede encontrar. Se trata de tener un segundo cerebro. Un cerebro que quizás construye pensamientos de una manera totalmente diferente a la tuya. Te ayuda a dar buenos nombres a clases, métodos y variables y a escribir un código más claro. A replantear la arquitectura, aplicar patrones de diseño útiles y resolver el problema desde una perspectiva diferente.

Esto nos permite no actuar según los primeros pensamientos. Pasar demasiado tiempo investigando un problema desde la perspectiva incorrecta o evitar distracciones. Además, ver cómo otras personas resuelven problemas puede enriquecer tus capacidades y habilidades.

Y finalmente, es una herramienta para aumentar la cohesión del equipo. No hay dinámica de equipo más sólida que tener que trabajar juntos en un problema real.

Pares y revisiones de código

Permíteme comenzar con una idea clásica: tenemos revisiones de código extremadamente buenas, el pair-programming es una pérdida de tiempo.

Cada vez que escucho esta afirmación, me vienen a la mente tres pensamientos. El primero es que se subestima el trabajo colaborativo. El segundo es que hay una falta de comunicación dentro del equipo o que no hay suficiente confianza como para hacer pair-programming. El último es que se quiere ir rápido, pero no es importante hacerlo de la manera correcta.

Cuando haces una revisión de código, comienzas a construir tu modelo mental desde el punto de vista del otro desarrollador. En la revisión de código, te pones en la mente de otra persona y buscas que la tarea se realice correctamente. Dado que este modelo mental no es tuyo, a menudo terminas estrechando la solución final para acomodarla al trabajo que se ha realizado.

El pair-programming, por otro lado, es una revisión de código constante en tiempo real, en la que de manera iterativa se busca la mejor solución y se construye un modelo mental juntos. No estamos revisando una solución final, estamos tratando de encontrar juntos el mejor enfoque para abordar un problema. Desde el principio, acordamos cuál es el problema.

En algunos casos, las personas piensan en excepciones a esta regla, por ejemplo, cuando dos programadores inexpertos hacen pair-programming. Pero si ese es el caso, ¿no sería una buena idea agregar a un tercer desarrollador más experimentado?

Y sabes qué, eso es perfecto para entornos remotos. El pair-programming mantiene a los desarrolladores en una colaboración constante y auténtica. No es necesario realizar actividades de construcción de equipos o adoptar una cultura empresarial extravagante para crear un entorno colaborativo; el pair-programming fomenta esta cultura de manera natural.

El pair-programming no se trata de velocidad

Nuestro sentido común nos dice que dos personas trabajando en el mismo problema reducirán a la mitad el tiempo necesario para completar una tarea. Sin embargo, eso no es cierto. El pair-programming es un 15% más lento en cuanto al tiempo de desarrollo. El pair-programming se trata de calidad, evitar retrabajos, ahorrar costos de mantenimiento, aumentar la sostenibilidad del código, reducir problemas de comprensión y evitar decisiones de arquitectura erróneas. La velocidad es un problema circunstancial, la calidad es un problema central para el negocio.

Existen algunas revisiones sobre los costes y beneficios del pair-programming. Alistair Cockburn y Laurie Williams escribieron en 2006 una revisión extendida [1], en la que concluyeron lo siguiente:

"El coste de desarrollo para obtener estos beneficios no es del 100% que podría esperarse, sino más bien del 15%. Esto se compensa con pruebas más cortas y menos costosas, y por supuesto una mayor garantía de calidad."

Como vemos, los beneficios del pair-programming son múltiples. Mejora la cultura del equipo, la comunicación y la calidad, todo sin afectar significativamente el rendimiento a corto plazo. En resumen, te ayuda a construir un equipo excepcional.