El antes y después del Pair Programming

0

Pair Programming.


Fue en la entrevista de Etermax cuando escuché por primera vez el concepto del Pair Programming. Antes era desconocido para mí. El hecho de estar programando dos personas en una misma tarea ¿Cómo podría ser mejor? ¿no es mejor tenerlos en tareas distintas? ¿no se trabaja más lento? ¿Qué ventajas y desventajas tiene? Voy a dar mi punto de vista y algunas experiencias que tuve, pero realmente la programación es un antes y un después con esta práctica.


¿Cómo impacta trabajar con Pair Programming?

El Pair Programming es una práctica que tiene muchísimas ventajas. Paso a listar sólo algunas de ellas:


  • Facilidad de incorporación de gente nueva al proyecto. Se puede juntar alguien nuevo con aun programador que sepa mucho del proyecto para hacer una feature. De esta forma se va introduciendo en código con un programador que sabe y conoce.
  • Facilidad al codear features complejas. Incluso aunque ninguno de los dos sepa cómo hacer un algoritmo, entre los dos hablando van a poder descifrarlo. Dos cerebros trabajan mejor que uno.
  • Un código más estructurado. En el peor de los casos trabajando cada uno por su lado terminan teniendo dos estructuras que simulan ser una. En el mejor de los casos con Pair Programming, se termina teniendo una estructura bien armada en la que los dos tuvieron que plantearse problemas hasta ponerse de acuerdo.
  • Aprendizaje y sentimiento de apoyo para novatos. Soltar a alguien que no sabe C++ en un proyecto con este lenguaje sólo vs acompañarlo con alguien experimentado tiene claramente un impacto distinto. No solamente va a aprender más rápido preguntando y con un programador que sabe y entiende, sino que también se va a sentir más acompañado.
  • Mejora de comunicación entre programadores. No hay mucho que decir. Al estar juntos se van a poder crear charlas y planteos que de otra forma se verían reflejadas en discusiones en reuniones.


Insisto, éstas sólo son algunas de las ventajas. Agrego un artículo que habla también de los distintos tipos de Pair Programming y qué otras ventajas tiene.


¿Qué diferencia hay entre trabajar dos en tareas distintas y dos en la misma tarea?

Supongamos que me junto con un amigo y queremos hacer un nuevo juego desde cero. Ambos somos programadores. La lógica diría que si cada uno se concentra en tareas distintas vamos a avanzar más rápido ¿no?. Puede ser. Ahora, si ya pasaron por esta etapa en algún trabajo o proyecto, ¿Cuántas veces les pasó de querer juntar las dos partes y que sea más difícil la unión que las tareas en sí? A mí demasiadas. Es el meme de la pantera rosa.



Recuerdo una vez en un proyecto que quedamos con mi compañero en “Vos hacé la parte de IA y yo del personaje”. Al principio todo bien, pero no pasó mucho tiempo hasta que empezamos a pasarnos una documentación con explicación de qué hacía cada parte del código o dónde encontrar tal o cual cosa. ¿Saben cómo lo solucionamos? Nos tuvimos que juntar para ver el código. En otras palabras, una especie de Code Review o un Pair Programming.


Por otra parte, tuve proyectos desde cero con Pair Programming y la verdad que son muy dinámicos. Te dejan con la seguridad de en qué dirección va el proyecto y que ambos están en la misma página.


¿Cuál es más rápido? ¿Programar con alguien o sólo?

Yo creo que depende. A corto plazo quizás es más rápido trabajar sólo, pero a largo plazo seguro es más rápido trabajar en conjunto. Imaginen que cada código que se hace sólo es un desconocimiento para el resto. Mientras más se avance sólo más va a ser el porcentaje que el equipo desconozca. ¿Y un Code Review no soluciona esto? Puede ser, pero si nos vamos a juntar una vez por semana para ver qué hizo cada uno como si fuese una presentación para eso usar ese tiempo trabajando juntos. Además, no es lo mismo ver el código finalizado que estar programando. Se pierden muchas decisiones y puntos de vista.


¿Esto significa que siempre hay que hacer pair programming?

La respuesta es no. Siempre buscamos la Silver Bullet que sea perfecta, y a veces nos puede traer más complicaciones.


No todos están preparados para hacer Pair Programming. Me gusta compararlo con ir al psicólogo. Te puede ayudar muchísimo si te toca uno bueno, pero puede ser muy peligroso y te puede destrozar si vas con alguien no preparado. Me ha tocado trabajar con perfiles muy duros y exigentes de mala manera. Muy cerrados a lo que ellos creían y muy poco pacientes ante el fracaso. Esto puede generar fricciones, mala comunicación, peleas, un mal ambiente, entre otras cosas. También, es peor cuando alguien negativo tiene que hacer pair con alguien nuevo, donde sólo entorpece su crecimiento. En estos puntos, hay que estar muy atento a qué pairs se hacen y con quién.


Además del Pair Programming también existe el Mob Programming, donde básicamente en vez de ser dos programadores son más. Voy a hablar de esto en otro momento, pero personalmente considero que la efectividad del mob programming tiene más chances de caer mientras más programadores hay. Lo que sí puedo ir adelantando es que tuve semanas difíciles por un Mob Programming mal planteado, donde sólo una persona o dos a lo mucho trabajaban y el resto estaba haciendo otra cosa.


Dejando de lado las experiencias negativas, no todas las razones por las que no hacer pair son malas. Cuando hago una Game Jam trabajamos al principio en Pair/Mob para estructurar bien el código y luego nos separamos para atacar cada feature por separado, porque tenemos un tiempo límite y ya trabajamos tantas veces juntos que entendemos como trabajamos. Por otro lado, puede también no sólo ser en una Jam. Puede ser que hubo un problema en producción y hay que salir cada uno corriendo a arreglar distintos problemas. Insisto, todo depende del contexto.

Conclusión

Como todo, no hay una respuesta que resuelva todos los problemas. Como siempre, todo depende del contexto en el que estás. En mi caso, sí me ayudó muchísimo y es algo que voy a seguir recomendando y haciendo. No hay proyecto o feature nueva que no empiece con Pair Programming, porque realmente considero que los mejores proyectos y donde más seguros nos sentimos con el código fueron siguiendo esta práctica.


Por último, como recomendación, traten de no casarse con ninguna metodología. No todo es perfecto y no todo es un desastre. Si uno se ciega de que encontró la solución perfecta o de que una metodología no sirve para nada sólo va a tropezar con problemas.


¿Y ustedes? ¿Conocían el Pair Programming? ¿Lo probaron? ¿Cómo les resultó?

Entradas que pueden interesarte

Sin comentarios