Pair Programming Simplificado

En este post, comparto una pequeña definición de pair programming y explico los distintos estilos de pairing. Luego hago un repaso general de los beneficios, desafíos y desventajas de adoptar esta práctica. Por último, presento algunas herramientas que, para nosotros en Codurance, han sido fundamentales al momento de hacer pairing a distancia. 

¿Qué es pair programming?

El Diccionario de Cambridge define el pairing como:

Dos personas o cosas que se han colocado en pareja, o el acto de emparejar a dos personas o cosas. Al aplicarlo al desarrollo de software, significa: dos personas que trabajan juntas, en equipo, para obtener un determinado objetivo. 

El pairing es una de las prácticas de eXtreme Programming (XP) que fueron formuladas a finales de los años 90 por el gurú de desarrollo de software, Kent Beck. Ha sido utilizada una y otra vez en distintos dominios y proyectos (desde los más pequeños y simples a los más grandes y complejos), generando implementaciones sorprendentes y exitosas.

Pero, ¿por qué hacer que dos personas hagan el trabajo de una? ¿No afecta esto directamente a la productividad? Si hubiera que hacer dos tareas, se necesitaría el doble de tiempo y de recursos. Mientras que uno escribe el código, el otro lo supervisa. Pero, ¿por qué? Parece una locura...¿O no?

Para entender esto, tenemos que repasar nuestro concepto de "coste". Si pensamos a largo plazo, ¿qué significa "coste" en términos de dinero y tiempo? Por muy complejo que sea el problema, ¿siempre se necesitaría el doble de tiempo para completar un par de tareas si dos personas trabajan en ellas? ¿Y si hablamos en términos de calidad? En los siguientes párrafos revelo  la metodología detrás de esta "locura".

Pero antes, os dejo algunas citas de los grandes de la industria: 

Jean Bartik (Una de las mujeres ENIAC, consideradas por muchos las primeras programadoras)

Kent Beck

Diferentes estilos de Pair Programming

Empecemos con cómo se hace una sesión de pairing.

Hay distintos estilos de pair programming. Cada uno de ellos tiene sus ventajas y desventajas. Así que debes elegir el estilo que mejor se adapte a ti y a la tarea que vayas a realizar.

• Driver & Navigator: el driver es la persona que controla el mouse y el teclado (es decir, la que lleva el volante). Quién cubra este rol siempre deberá comunicar continuamente lo que hace mientras lo hace. En comparación con el driver, el navigator tiene un rol mucho más pasivo. Él revisa el código y da su opinión al respecto, mientras que el driver lo desarrolla. También se encarga de hacerle seguimiento al objetivo principal y detectar posibles bugs. Esto lo hace siguiendo las mejores prácticas y tomando nota de los posibles pasos u obstáculos a enfrentar. La dinámica del driver-navigator funciona muy bien cuando dos expertos trabajan juntos e intercambian roles regularmente. 

• Strong-Style pairing/ Backseat Navigator: aquí, la regla de oro es la siguiente:

"Para que una idea pase de tu mente a un ordenador, primero DEBE pasar por las manos de alguien más".

En este estilo, normalmente el navigator es quien tiene más experiencia con el setup o la tarea en cuestión, mientras que el driver es un principiante (en relación al lenguaje/herramientas/dominio/codebase, etc...). Así, la persona experta asume el papel de navigator y guía al novato. Aunque esta técnica se acerque mucho al enfoque "haz lo que te digo", puede ser una herramienta útil de onboarding que le permita al principiante aprender a través de la práctica.

• Tour Guide: al igual que el Strong-Style/ Backseat Navigator, el estilo Tour Guide funciona mejor con la combinación experto-novato, especialmente cuando se trabaja con novatos primerizos. El driver (experto) se encarga del razonamiento estratégico. La diferencia es que también se encarga de redactar el código. Mientras esta en ello, informa al "turista" (novato) sobre lo que está haciendo. Esto sucede de la misma manera en que un guía turístico explica a un turista los distintos lugares de interés. El turista raramente interviene o desafía al driver. La discusión sobre la implementación del código se hará una vez finalizado el test. Este estilo de pairing corre el riesgo de que el novato (turista) se desinterese después de cierto tiempo. A pesar de esto, el driver (guía turístico) continua con la sesión.

• Ping Pong: la mayoría de los programadores opinan que este es el estilo más interesante y probablemente por eso se ha convertido en el más adoptado. Este estilo tiene un factor de diferenciación con respecto al resto: es completamente compatible con el Test Driven Development (TDD). Por este motivo, es perfecto para cuando se tiene una tarea bien definida que puede ser implementada de forma test-driven. 

"Ping": el primer programador escribe un código que fallará el test.

"Pong": el segundo programador escribe un código de implementación para pasar el test y continuará escribiendo un nuevo test que fallará (Ping). Luego, le pasara este test al primer programador para que ejecute la implementación (Pong)...y así sucesivamente. 

También se puede responder cada "Pong" con una refactorización del código antes de pasar al siguiente test fallido. De esta manera, se sigue el ciclo "Rojo-Verde-Refactorización".

• Pairing a distancia: en un mundo cada vez más disperso, es común ser parte de un equipo cuyos miembros trabajan ocasionalmente/permanentemente desde casa. El pairing también se puede realizar a distancia siempre y cuando ambos participantes tengan una conexión a internet razonablemente estable.

Esto es más una modalidad que un estilo, así que puede ejecutarse siguiendo cualquiera de los estilos mencionados anteriormente.

Para el pairing a distancia necesitarías mantener una pantalla compartida que te permita ver y, si es posible, controlar el ordenador de tu compañero, de manera que puedas cambiar el teclado, marcar correcciones, hacer sugerencias, etc. Hoy en día, muchas herramientas de videoconferencia permiten compartir la pantalla, algunas de ellas son: Microsoft Teams, WebEx, etc. También existen herramientas open source para realizar videollamadas con control remoto.

Beneficios del pair programming

El pair programming tiene innumerables beneficios. A continuación se especifican algunos de ellos:

• Menos bugs y errores: cuando los desarrolladores de software trabajan solos, el código es sometido a matices subjetivas. Esto puede ser tan sencillo como malinterpretar los requisitos o apegarse rígidamente a un patrón de diseño. Con la programación en pareja, las personas pueden intercambiar ideas para resolver este problema. Esta práctica le permite al navigator pensar de manera abstracta y prever los casos de uso que la implementación debe satisfacer (mientras el driver la implementa). Esto permite que existan actividades de implementación y planificación paralelamente. ayuda a reducir bugs, errores y dificultades encontradas con el testing.
  
• Mejor calidad y velocidad: con el pair programming el feedback es inmediato ya que el segundo desarrollador puede cuestionar o corregir al primero en tiempo real. Esto ofrece una gran oportunidad de intercambiar ideas y optimizar el código desde el inicio. De este modo, se mejora la calidad de la implementación. En la mayoría de las organizaciones de software, habrá un "Code Review" en el proceso de desarrollo informático. El pair programming agiliza este proceso, ya que el código se revisa constantemente a medida que se escribe. Un feedback más rápido conduce a un desarrollo más rápido
• Responsabilidad: cuando se trabaja solo, siempre existe la posibilidad de que, debido a la presión de los plazos o al cansancio, algunos problemas se guarden bajo la alfombra y se acumule deuda técnica. También hay casos en los que los desarrolladores usan atajos para realizar la implementación. El pair programming hace que los desarrolladores se responsabilicen de todo el código que escriben. Los desarrolladores deben enorgullecerse de su código y el pair programming ayuda dándoles confianza en sí mismos. 
• Intercambio de conocimiento: uno de los factores más importantes para que un equipo sea rápido es la amplitud de su conocimiento. Este último, le permite a cualquier miembro del equipo desarrollar, arreglar o refactorizar cualquier parte del código.

Esto significa que el intercambio de conocimiento debe ser un proceso continuo. Debe hacerse mientras se trabaja. 

Pair programming ofrece la oportunidad de compartir conocimiento de forma continua. De este modo, más de una persona sabe exactamente porque el código se escribió de la manera en que se hizo, lo que implicó tomar las decisiones de diseño, los obstáculos enfrentados y las soluciones utilizadas. También elimina el cuello de botella que se genera cuando sólo una persona conoce el código y, de esta forma, reduce dependencias.

• Capacitaciones más rápidas: el pair programming suele ser entre dos desarrolladores de nivel medio o senior, o una combinación de principiantes y seniors. Esto proporciona el escenario perfecto para estimular el training en el trabajo. Los principiantes pueden utilizar la sesión para aprender rápidamente el dominio, las prácticas de codificación y quizás también algunos trucos; mejorando la moral del equipo y la colaboración.

El pair programming permite formar parejas con diferentes personas del equipo durante distintas fases del desarrollo. Fomenta la colaboración activa y mejora la capacidad del equipo de comunicarse y trabajar juntos. El que tengamos que explicar nuestra forma de pensar ayuda a entender nuestro proceso de razonamiento. De manera similar, la otra persona debe escuchar y responder a los pensamientos de su compañero. En general, esto mejora la comprensión mutua y la moral del equipo. Incluso podría convertirse en un ejercicio de team-building para mejorar la productividad.

Desafíos comunes durante el pair programming

Uno de los mayores argumentos en contra del pairing es el riesgo a que un miembro asuma el dominio del ejercicio y se pierda la esencia colaborativa. 

Esto sucede cuando los miembros del equipo han trabajado aisladamente durante toda su carrera y no están acostumbrados a compartir el proceso de desarrollo con nadie más.

Hay algunas medidas que se pueden tomar para mitigar este aspecto:

• Acordar turnos antes de empezar: no hacerlo es un error básico cuando se trata de hacer sesiones de pairing eficaces. 

Esto siempre permitirá que el compañero menos dominante tome el volante regularmente.

Lo ideal es cambiar turnos cada dos horas, independientemente del progreso y del estado del codebase.

• Separa tus soluciones: Si la otra persona adopta su solución sin tener en cuenta tu feedback, proponle que tú la hagas en una rama separada.

Eventualmente, algunas de las soluciones no funcionarán y, cuando esto suceda, podrás revertir rápidamente el error y probar tu solución.

De esta manera evitarás cualquier disputa innecesaria al inicio de la sesión.

• Intermediación del líder: invita al líder del equipo o a uno de los desarrolladores senior a la sesión para que actúe como moderador.

Sin embargo, no debemos permitir que esto se convierta en una práctica estándar o una necesidad constante.

Un puñado de sesiones deberían bastar para corregir la dinámica de la pareja. 

Desventajas del pair programming (y cómo superarlas) 

Repasemos algunas de las desventajas del pair programming:

• El coste: hay un aspecto (ilusorio) sobre el coste del pair programming que es difícil de ignorar por quienes nunca lo han practicado. 

Para un manager que es nuevo al pair programming, la idea de utilizar dos recursos para una misma tarea es difícil de aceptar. La pregunta suele ser: si dos personas realizan la tarea, ¿tomará la mitad del tiempo completarla? La respuesta es: no a corto plazo. Sin embargo, dará resultados equivalentes o mejores a largo plazo. Estos beneficios se verán reflejados no solo en el tiempo de duración, sino también en otras áreas. Pero para quién no conoce este ejercicio, ese futuro no es más que un espejismo lejano.

• Observar al experto: este es uno de los riesgos de las sesiones de tipo driver-navigator.

Si el driver tiene mucha más experiencia que el navigator, y este tiende a adueñarse del tiempo en el teclado, existe el riesgo de que el navigator pierda interés. Para el navigator se vuelve más fácil observar al driver y asentir. Esto anula el propósito del pair programming.

• Complicar tareas sencillas: en situaciones en las que la tarea es sencilla existe el riesgo de que el pairing la complique innecesariamente.

Lo mismo puede decirse cuando se debe hacer una investigación antes de empezar a codificar. Emparejarse para buscar la solución en un solo ordenador no es óptimo. Es mejor que una sola persona se encargue de este tipo de tareas y que el pairing se reserve para tareas complejas. La mejor manera de llevar a cabo las actividades de investigación es que cada uno de los participantes lo haga individualmente. Después pueden compartir sus resultados y decidir conjuntamente el siguiente curso de acción.

• Conflictos de personalidad: siempre hay un elemento humano cuando se trabaja en equipo. El propósito del pair programming es mejorar la productividad. 

Si la pareja es conflictiva o no se lleva bien, juntarla puede ser contraproducente. Por este motivo, tiene que existir un cierto nivel de respeto y confianza. Al fin y al cabo, el respeto es uno de los 5 valores de XP.

• Es difícil: Cualquier cosa nueva es difícil y el pair programming no es la excepción. La idea de programar en parejas todo el día, todos los días, es demasiado abrumadora cuando se esta iniciando. Así que es mejor empezar poco a poco. La productividad es el aspecto clave. Hacer sesiones más cortas, con descansos frecuentes y distintas parejas ofrece variedad y ayuda a mantenerse concentrado. 

Herramientas de Pair Programming a distancia

Luego de la pandemia muchas cosas cambiaron, no solo en la industria del software sino también en la distribución y estructuración de equipos. A menudo, los miembros de un equipo se encuentran distribuidos en pueblos, ciudades, países e incluso continentes distintos. Así que en algunos casos las sesiones podrían denominarse pair programming a distancia; es decir, pair programming realizado por dos o más desarrolladores que se encuentran en lugares distintos. Por lo tanto, tendría que llevarse a cabo a través de herramientas para compartir pantalla o IDE (mejor conocido como entorno de desarrollo integrado).

Para satisfacer esta necesidad, se han creado varias herramientas de programación a distancia. Cada una de las herramientas de esta lista entra en al menos una de las siguientes categorías:

IDE Colaborativo: las herramientas de esta categoría le permiten a los usuarios invitar a otros programadores a colaborar en su IDE. En esta categoría sólo se comparte el IDE. 

Single user sharing, dual/multiple user control: en esta categoría tenemos herramientas que le permiten a un usuario compartir su pantalla mientras otros usuarios pueden verla y controlarla. Solo un usuario puede compartir la pantalla a la vez; sin embargo, tanto él como los espectadores pueden controlar el dispositivo.

Multi-user sharing, multi-user control: las herramientas de esta categoría ofrecen el mayor nivel de interactividad ya que permiten que varios usuarios compartan y controlen las pantallas al mismo tiempo. 

• Categoría: IDE Colaborativo

• Categoría: Single user sharing, multiple user remote control

• Categoría: Multi-user sharing, editing and multiple user remote control.

CoScreen
CoScreen es una gran herramienta que los equipos pueden utilizar para compartir pantallas, editar y trabajar en el código juntos. También ofrece la posibilidad de que varios usuarios compartan su pantalla.

Otra característica destacada de CoScreen es que permite compartir una ventana específica de la aplicación. Es decir, los usuarios pueden compartir una ventana, dejar de compartirla y compartir otra ventana sin problemas, todo ello con un solo click.

CoScreen es compatible con Windows y macOS.

Otras herramientas destacables son:

• CodeSandbox Live
• Codeanywhere
• CodeTogether
• CodePen
• MotePair by Atom
• Teletype for Atom

Conclusión

Puedes amarlo u odiarlo, pero el pair programming es un proceso comprobado que, cuando se hace bien, mejora la productividad y da como resultado un código de buena calidad. Es difícil de realizar, pero sin duda merece la pena. Es como la vista desde la cima del Everest: fenomenal. Lo bueno de la programación en parejas es que no es tan difícil como escalar el Everest, pero proporciona la misma felicidad sublime. Pruébalo y disfruta... :)

Algunos de los entornos de pair programming que se mencionan aquí pueden tener costes.