¿Por qué funciona Pair Programming?

Cuando se presentan las prácticas de Extreme Programming hay una que inmediatamente genera un rechazo especial: Pair Programming. Ese rechazo es completamente comprensible, ya que estamos poniendo a dos personas a hacer el trabajo que antes hacía uno. ¡El proyecto va a llevar el doble de esfuerzo! - grita el lider del proyecto, y al doble de Costo!! - corea desde su oficina el gerente de proyectos, estos programadores vagos que no quieren trabajar!!

Sin embargo, hay bastante evidencia de que trabajar de a pares nos hace más productivos. ¿Cómo puede ser?

La principal explicación es que programar no es una tarea mecánica. La única parte más o menos mecánica es el tipeo del código y es una tarea que no consume mucho tiempo. En un proyecto en el que participé medí la cantidad de código que habíamos generado y la dividí por la cantidad de horas de desarrollo. El resultado fue que habíamos escrito algo así como unas 15 líneas de código por hora (y esto en un proyecto que fue completado exitosamente en el tiempo estimado).

Las tareas que verdaderamente se llevan el tiempo de desarrollo son otras, como descubrir lo que el usuario quiere que desarrollemos, entender el código existente para ver a donde nos conviene agregar las partes nuevas, diseñar la implementación, entender como usar nuestras herramientas y corregir bugs.

Pair programming funciona porque todas esas tareas se hacen en forma más eficiente en pares. Es más facil entender requerimientos o código o herramientas cuando discutimos con un par (y además es probable que uno de los integrantes del plan ya tenga experiencia al respecto) y es mucho más productivo hacer sesiones de brainstorming de a pares para pensar alternativas de diseño.

En cuanto a la corrección de bugs, trabajando de a pares disminuye, y mucho, la cantidad de errores introducidos debido a la constante revisión del código por dos personas. La búsqueda de los pocos errores que se producen también es más eficiente, simplemente por la necesidad de comunicación dentro del par. El efecto es parecido al que se da cuando nos rompemos la cabeza durante horas tratando de solucionar un problema y cuando finalmente pedimos ayuda y tratamos de explicar el problema a alguien, se nos ocurre la solución, antes de que la otra persona tenga tiempo de decir una palabra.

La productividad además aumenta porque disminuyen las distracciones y aumenta la focalización en los problemas. Esto a primera vista parece paradójico porque con dos personas uno pensaría que crece la posibilidad de divagar o distraerse. Sin embargo no es así, y la necesidad de concentrarse no solo en solucionar el problema sino, además, en comunicar con el par lo que uno cree que debe hacerse y discutir sobre la solución, todo esto evita que uno se distraiga con ruidos externos o con llamadas o la llegada contínua de mails molestos.

Por ultimo el compartir entre dos desarrolladores de diferentes niveles de skill y conocimiento constituye la mejor y más rapida forma para poner al dia a un nuevo programador que se incorpora al equipo. Y ademas, el más experimentado recibe una dosis frescas de dudas y cuestionamientos a ciertos temas que "siempre han sido asi" pero que no tienen porque serlos.

En definitiva, los programadores no trabajamos levantando paredes ni en una línea de montaje de una fábrica, por mencionar dos metáforas conocidas en nuestra profesión ("factorias de desarrollo") . Trabajamos pensando y ese tipo de trabajo se hace en forma más eficiente en equipo.