ElBruno ha escrito un interesante artículo en su blog titulado “[#ALM] DEMOSTRANDO CON NÚMEROS PORQUÉ ES CONVENIENTE REALIZAR PAIR PROGRAMMING” en el que, mediante lo que considero un ejercicio de razonamiento, intenta demostrar el incremento que esta práctica puede generar en la productividad de un equipo con una configuración ficticia, aunque bastante común, de 2 Devs. Srs. y 4 Devs. Jrs.  Recomiendo su lectura (y además, es condición necesaria para entender de que se habla en esta entrada).

En primer lugar debo aclarar que todo intento por ayudar a difundir, y animar a implementar, esta y otras prácticas es de agradecer e imitar. Además, y solo para dejar explícita mi posición acerca de esta práctica (Pair Programming), debo decir que estoy absolutamente de acuerdo con ella, incrementa la calidad, los diseños, la comunicación y el conocimiento del equipo como pocas prácticas lo hacen. Y además es más sociable y divertido mientras que eleva el compromiso.

Ahora, una vez aclarado esto, debo decir que a mi humilde entender ElBruno no ha acertado en su enfoque. ¿Por qué? Veamos, para demostrar la hipótesis, utiliza el siguiente ejemplo:

El problema con la argumentación es que todo el modelo cierra cuando existe una cantidad de desarrolladores juniors los cuales no pueden completar su trabajo sin quitarles tiempo a los desarrolladores seniors, de esta forma y en este contexto parece que la propuesta es una buena idea para maximizar la productividad. Lo curioso es que según el ejemplo, la mejor solución sería eliminar esos 4 factores de anti-capacity llamados juniors y así, con solo una fracción del costo, los 2 desarrolladores seniors podrían completar sus 2 unidades de trabajo diarias con lo que a la semana tendríamos 20 unidades de trabajo completas. Entonces, es la existencia de esos juniors la condición necesaria para que esto cierre.

No obstante creo que aquí se cumple una gran verdad: poner más desarrolladores, poco experimentados, no incrementa la velocidad del equipo; y como este modelo concuerda con las experiencias de la vida misma, podemos pensar que no está muy lejos de ser correcto.

Ahora, este mismo razonamiento no arroja los mismos resultados si el equipo tuviese otra configuración como por ejemplo si fuesen solamente 6 Devs. Srs. En este caso, si aplicamos el mismo razonamiento utilizado en el ejemplo, el resultado será que como nadie requiere ayuda de otro para terminar (o al menos idealmente), entonces tener a 2 Devs. Srs. en una misma máquina resultaría en una pérdida de la productividad.

Como Pair Programming es exactamente para, entre otras muchas cosas, incrementar la calidad y con esto reducir los costos, creo que esta argumentación podría habilitar a aquellos quienes desconocen la práctica, detractores por ignorancia, a jugar con modelos similares concentrándose en la economía evidente (para ver “si les conviene” o “no les conviene”) ignorando la disminución del costo a largo plazo que esta logra. Quizás, como todo el ejemplo cierra gracias a estos 4 devs. juniors alguien podría argumentar que su equipo no necesita de esta práctica ya que el mismo se compone solo de devs. seniors. Así las cosas, este argumento es de doble filo!

Otro motivo por el que este ejemplo no me parece el mejor es porque, en mi experiencia, Pair Programming funciona mucho mejor cuando ambos desarrolladores tienen conocimientos “equivalentes” y no tan bien cuando la diferencia de conocimientos es grande como entre un junior y un senior. En este último caso, el juniors casi siempre se limita a mirar (y en el mejor de los casos a aprender, que no es poco) pero difícilmente pueda darse la dinámica de cambiar con cierta frecuencia el teclado y los roles.

Por desgracia esta práctica es quizás la menos utilizada y esto se debe entre otras cosas a que es difícil de demostrar de manera “teórica” lo que la hace no muy evidente. Otro problema es que en varios papers de señores científicos que publican en la IEEE y la ACM se menciona que esta incrementa el time to market en entre un 15-20% y por eso es también que se hace mucho más difícil de justificar. En el tiempo de los resultados rápidos pocos quieren invertir a largo plazo.