Sacando lo mejor de la programación en parejas

La programación en parejas (o "Pair Programming" en inglés) es una de las prácticas más mencionadas de la Programación Extrema (conocida como XP o eXtreme Programming). Programar en parejas significa tener a dos desarrolladores compartiendo un mismo ordenador para realizar determinada tarea. Uno de los dos escribirá el código mientras el otro lo ayudará a mantenerse en el camino correcto. Suena un poco loco, yo sé, pero al final puede ser muy productivo siempre y cuando se realice de la forma adecuada.

Cómo descubrí su valor

Hace unos cuantos años atrás tuve la oportunidad de trabajar en varios proyectos con un amigo, los dos, la mayor parte del tiempo, compartiendo el mismo puesto de trabajo (¿te acuerdas Rigre?). No había ninguna teoría que sustentara el hecho de que ambos utilizáramos en aquel entonces un solo equipo, sino una realidad que, desde cierto punto de vista, veíamos como un problema: sólo teníamos una computadora, así que no quedaba otro remedio. La experiencia resultó ser extremadamente productiva: ambos aprendimos mucho, y estoy convencido que los niveles de calidad que alcanzamos en el código hubiesen sido imposibles trabajando separados.

La matemática nunca falla: cuatro ojos ven el doble que dos, y dos cerebros piensan el doble que uno, así que programar en parejas tiene, por fuerza, que ser beneficioso. Cuando ya tenía mi propia computadora, y luego de que la primera experiencia fuera positiva, practiqué varias veces más con otros compañeros en diferentes proyectos y momentos, ya no por fuerza, sino por convencimiento de las ventajas que podía tener. Realmente no pude quedar más satisfecho con los resultados.

Es impresionante cuánto puede aportar una persona que viene a un proyecto con la mente fresca y un punto de vista diferente. Las posibilidades de atascarnos pensando en cuál será la mejor solución para esto o aquello quedan reducidas dramáticamente. Siempre hay una idea en el aire, siempre uno tiene una mejor opinión. El código, por supuesto, es el más beneficiado, y con él, nosotros que somos los encargados.

Pero no todos concuerdan al respecto

Sin embargo, muchas veces hablarle al "Big Jefe" de que vamos a programar de dos en dos puede ser un tanto traumático. Los invito a que hagan la prueba y verán como le amargan el día en un dos por tres al encargado de firmarnos los cheques. Para él los números son bien simples: "dos personas trabajando en lo mismo significa la mitad de productividad". ¿Cómo explicarle las ventajas que tiene esta historia? Y aunque encontremos las palabras justas y un saco de enlaces en Internet para soportar nuestra propuesta, ¿creen que el jefe compre y nos deje compartir nuestro tiempo en el mismo escritorio? No tan simple.

Y yo soy el primero que siempre estoy llorando por "incomprendido" y por el abuso de jefes "ignorantes" que no saben nunca nada sobre desarrollo de software, pero seamos realistas: ¿no habrá un poco de razón en ellos? ¿O es que acaso todos están equivocados y la razón es solo nuestra? Cuando lo pienso, no me queda otra que entender las fuerzas que les provocan mala digestión cuando se nos ocurren ideas como programar en parejas:

1. Dos piensan más que uno, cierto, pero en defensa de los que se niegan, dos abarcarían más que uno también si trabajaran en cosas diferentes. Como quiera que se mire, unos y otros pudieran tener la razón, así que el argumento matemático sirve de escusa para cualquiera de las dos posiciones.
2.  En una empresa por lo general hay varios proyectos llevándose a cabo al mismo tiempo, por lo que la fuerza de trabajo (no siempre abundante) tiene que ser distribuída correctamente. No se puede simplemente poner los proyectos en cola donde todos acabamos el primero, y luego vamos para el segundo. El desarrollo tiene que realizarse en paralelo.
3. Muchas veces los desarrolladores se encuentran especializados en áreas diferentes, por lo que resulta muy difícil comulgar con la idea de que ambos van a trabajar en lo mismo a la misma vez. Más logico parece el escenario donde el trabajo de los dos se integre cuando cada cual termine su parte.

¿Y hay que resignarse entonces?

Sin embargo, a mi nadie me contó que programar en parejas funcionaba. Yo lo he vivido de primera mano, así que ninguna percepción por muy lógica que parezca puede evitar que haga todo lo posible por hacer mi trabajo de la mejor manera. Quieran o no, yo tengo que convencer a quien sea de que "dos" pueden lograr cosas que "uno" solo ha visto en sueños, y para conseguirlo - como en toda buena negociación - hay que saber adaptarse a las circunstancias y ser flexibles acorde al momento.

Antes de convencer a alguien, lo primero es ser conscientes que programar en parejas no puede ser una obligación y un "si no lo haces estás mal". Esas imposiciones se las dejamos a los muchachos de XP para los cuales no hay colores intermedios entre el blanco y el negro. Nosotros somos más inteligentes y vamos a analizar las cosas como funcionan en la vida real: cuando estamos "creando", una pareja es una bendición. Cuando estamos "reproduciendo", la pareja es un estorbo que pierde su tiempo babeándose a nuestro lado.

En todo proyecto hay momentos de "creación", donde los programadores estamos haciendo "arte" y necesitamos de todas las ideas geniales que podamos obtener. Son los momentos en los que hay que pensar y tomar decisiones que marcarán el éxito de nuestro proyecto. Es allí cuando un compañero más ayuda. Es allí donde necesitamos ese punto de vista diferente que nos guíe por el camino correcto. Sin embargo, hay etapas donde el cerebro trabaja poco o nada, todo lo que hay que hacer podemos recitarlo de memoria mientras nos damos una ducha. Estamos en modo "reproducción", donde simplemente estamos siguiendo los pasos para llegar al nuevo punto de "creación". Allí cualquier ayuda externa es bienvenida pero de muy poco valor probablemente.

Si lo hacemos bien, todos quedan contentos

No podemos ser drásticos y echarnos a llorar cuando nos digan que no. Tampoco podemos usar una pistola para que se haga nuestra voluntad, así que sutilmente tenemos que lograr aprovechar al máximo las ventajas de programar en parejas sin asustar a nadie. Esto puede lograrse con un poco de sentido común, haciendo lo mejor posible para combinar nuestros intereses con los de nuestra empresa, haciendo una fusión de las ventajas de programar solo con las de programar en parejas.

Últimamente es así como trabajo: nos sentamos juntos, hablamos de qué hay que hacer y cómo hacerlo, y cuando el que va a desarrollar está 100% consciente de cómo llegar a la meta, nos separamos y cada cual a lo suyo. Ese ciento por ciento "de consciencia" significa que todo lo que queda entre ese instante y la próxima parada es modo "reproductivo". El tamaño del camino puede variar, pero ganarse el privilegio de sentarse solo sin alguien mirando sobre tu hombro significa que tú solo te bastes para completar la tarea sin contratiempos. En cuanto aparece una piedra difícil de saltar, aunámos esfuerzos nuevamente y el ciclo continúa.

Básicamente esto se traduce en que un 70% del tiempo estemos por nuestra cuenta (y esto es un número que me acabo de inventar con el propósito de que se entienda mejor. Realmente considero que el tiempo que se emplee solo o en parejas es muy difícil de predecir / calcular de antemano). Quizás no sea lo recomendado, pero es mucho mejor que la soledad absoluta. En los momentos más necesarios buscamos compañía y esto hace toda la diferencia. Particularmente he podido notar que esta dinámica es aplaudida por todos cuando la explicamos correctamente al ser preguntados. Al principio no podemos evitar el clásico "¿Por qué están los dos juntos? ¿No pueden separarse para adelantar más?", pero un simple "Estamos decidiendo cuál es la mejor variante para seguir" calmará las aguas sin mayores problemas.

¿Y cuáles son los puntos a recalcar?

Obviamente que en algún momento tendremos que justificar seriamente la dinámica de dos programadores juntos de cuando en vez. En muchos casos los responsables sobre nuestras cabezas simplemente "dejan hacer", pero en otros, quieren estar empapados de cada detalle del proceso, así que nada mejor que tener preparados los siguientes puntos para que todos entiendan por qué estamos en lo correcto:

• La mejor respuesta de toda es cuando podemos demostrar con productividad lo que hacemos. Un ejemplo real donde programar en parejas significó un punto de inflexión favorable en un proyecto es la mejor arma para lograr asentimientos.
• El número de errores que pueden aparecer en etapas críticas en nuestro proyecto será mucho menor que si trabajamos solos.
• Para la toma de decisiones importantes en cuanto al diseño de nuestra aplicación, la experiencia de dos personas llevará a resultados mucho más consistentes que pagarán sus beneficios durante el ciclo completo de la aplicación.
• Cuando aparecen problemas durante el desarrollo, dos personas pueden encontrar la solución mucho más rápido que una sola.
• En los momentos en que dos programadores están trabajando juntos, ambos están beneficiándose mutuamente de los conocimientos del compañero, lo que provoca que la productividad de ambos aumente considerablemente.

Con todo esto en la mano, y haciendo que el proceso fluya sin mucho ruido, veremos como nuestra fusión comenzará a formar parte de nuestro quehacer diario sin mayores inconvenientes. Lo que un día pudo ser una frustración para los responsables de nuestros proyectos, puede convertirse en una bandera que los haga sentir orgullosos en conversaciones después del almuerzo. Al final, todos ganan... y nosotros mucho más que nadie.