La Programación en pareja es una de las prácticas más debatidas de Extreme Programming. Históricamente, la programación solía ser una actividad solitaria que requería de una alta concentración e incluso aislamiento total. Los mejores programadores saben como alcanzar un estado mental conocido como Fluir o Zona, en el cual la mente es capaz de enfocarse en el código y tomar decisiones sumamente creativas y eficientes.
Aunque Fluir es algo muy valioso y puede resultar más dificil lograr con una pareja, la realidad muestra que la programación solitaria es demasiado riesgosa y a largo plazo termina costando bastante más dinero para la organización. Repasemos los cinco riesgos más graves de programar en solitario.
Alta tasa de defectos
Este es el riesgo más obvio. Los seres humanos no somos magos y sin importar que tan preciso se intente ser, es inevitable que ocurran errores de tipeo, se comprenda mal el requerimiento o simplemente ocurra una equivocación. Los programadores solitarios enfrentan estos errores con ayuda de una planificación cuidadosa, revisiones de código y varias herramientas de análisis de código. Estas actividades son todas muy útiles, pero no existe ninguna revisión de código realizada después del problema que pueda compararse con una revisión continua que se hace durante el mismo acto de escribir el código. También, no hay cantidad de de planificación cuidadosa que se pueda comparar con estar junto al cliente, al analista de negocio o al tester mientras se trabaja con el requerimiento.
La programación de a pares no es la bala de plata que solucionará todos los problemas; simplemente resulta demasiado riesgoso presuponer que una única persona puede prevenir la misma cantidad de errores que una pareja.
Las distracciones que nos fuerzan a salir de la Zona
A un trabajador promedio de oficina se lo interrumple cada 11 minutos. No resulta sorprendente que a un programador le cueste tanto Fluir, y lograr código creativo y diseños eficientes. No es tan facil interrumpir a un par de personas que trabajan como un equipo. Para quienes están caminando por la oficina, es mentalmente más dificil atreverse a interrumpir a un equipo; la pareja en general apaga el centro de atención individual a su entorno. Además, incluso aunque la pareja sea interrumpida, a menudo se puede dejar a que uno resuelva el pedido importante y deje a su pareja "fluyendo", para luego unírsele nuevamente cuando la distracción queda resuelta.
La programación de a pares no es la bala de plata que solucionará todos los problemas; simplemente resulta demasiado riesgoso presuponer que un programador solitario puede ser tan resistente a las distracciones externas como una pareja.
Poca concentración y disciplina
Los programadores son personas bastante disciplinadas, pero a veces hay demasiados videos divertidos en YouTube, o algún artículo muy interesante (pero irrelevante en ese momento) publicado en algun sitio popular. Los motivos de distracción no son malos por si mismo, después de todo nadie puede escribir código creativo durante 8 horas seguidas.Sin embargo, cuando esta tentación se va de las manos, añade otra fuente de distracciones. Cuando se trabaja con un par, cada parte se siente naturalmente comprometida al objetivo, y las personas pueden seguir con sus objetivos puramente personales cuando se acaba el tiempo de trabajar con la pareja.
La programación de a pares no es la bala de plata que solucionará todos los problemas; simplemente resulta demasiado riesgoso presuponer que un programador solitario puede resistir las tentaciones que rompen la disciplina de forma tan efectiva como una pareja.
Pocos incentivos para seguir prácticas comunes
Cuando se aproxima la fecha de entrega, es facil olvidarse de la calidad de las pruebas unitarias, de realizar análisis de la arquitectura, de verificar que los nombres de las variables sigan los estándares de la organización, etc., etc. No resulta facil admitir esto mismo frente a una pareja. Justo al revés, es mucho más facil encontrar el coraje necesario para decirle a la gerencia que la tarea es demasiado grande, o para contarle a la pareja que uno no sabe cómo aplicar una práctica de forma eficiente.
La programación de a pares no es la bala de plata que solucionará todos los problemas; simplemente resulta demasiado riesgoso presuponer que a un programador solitario le resulta igual de facil seguir prácticas comunes como a una pareja.
Aprendizaje lento
Cualquier persona que ingresa a un equipo, tanto sea un desarrollador senior como alguien que se acaba de graduar, necesita tiempo para aprender los estándares del equipo, la forma en que trabaja y el código en si mismo. El aprendizaje en solitario puede llevar meses, y las personas más tímidas pueden terminar sin conocer el uso de una herramienta en particular. La programación de pares con un mentor o mentores reduce significativamente la cantidad de tiempo que se necesita para aprender distintos temas, comprender el código y unirse al equipo.
Por otro lado, el programador solitario sólo tiene a sus propios conocimientos y punto de vista para aprender. La programación en pareja, al rotar progresivamente por todos los miembros del equipo, enriquece constantemente a las personas, brindándoles nuevas experiencias, opiniones y perspectivas, logrando así un crecimiento personal y profesional continuo que resultaría imposible de alcanzar en forma aislada.
La programación de a pares no es la bala de plata que solucionará todos los problemas; simplemente resulta demasiado riesgoso presuponer que un programador solitario puede aprender igual de rápido como si estuviera junto a otro miembro del equipo.
¿Y sus riesgos cuáles son?
Seguro que se les pueden ocurrir otros riesgos de la programación en solitario. ¿Cuáles agregarían a esta lista?