Y soy de los que programan en solitario por varias razones, pero aunque nunca pude programar en grupo o en pares, sabia que por lógica programar al menos con alguien mas en un proyecto, debía ser siempre mejor que hacerlo solo. El caso es que leí dos artículos acerca de ventajas e “inconvenientes”  de la programación en grupos. Y no puedo estar más de acuerdo con las ventajas. Donde no estoy del todo de acuerdo es en los inconvenientes. Aquí un resumen de lo leído en el artículo titulado “Los 5 riesgos de la programación en solitario”:

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.

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.

Fuente: http://www.dosideas.com/noticias/reflexiones/401-los-5-riesgos-de-programar-en-solitario.html

En otro artículo que trata el mismo tema, expone un número de desventajas ademas de los beneficios.

Aun así, no todos los que añaden algún comentario al blog lo están también. Por ejemplo, hay quien da argumentos a favor del trabajo en solitario, como éstos:

• Propiedad total de las decisiones del diseño.
• Ser responsable de la agenda del proyecto.
• Poder fijar tus propias prioridades, sin necesitar alentar a otros a que vivan por ellas
• No necesitar actuar de “niñera” de desarrolladores menos experimentados
• Poder utilizar un proyecto para explorar una nueva tecnología, sin tener que justificar la decisión a otros miembros del equipo o a encargados de proyecto
• Poder comunicarse directamente con los clientes sin tener que trabajar a través de intermediarios (como encargados de proyecto o analistas).
• No hay que ocuparse de código heredado de otros desarrolladores; como todo el código es el mío, mi familiaridad es mayor.
• Poder elegir qué lenguaje y qué base de datos utilizar para los nuevos proyectos.
• No tener que perder ni una hora en reuniones del equipo ni con los encargados

Fuente: http://nachocabanes.blogspot.com/2007/06/uno-es-el-numero-mas-solitario.html

La primera ventaja de trabajar en solitario no la veo como tal. Piensa que si te equivocas, toda responsabilidad recae sobre ti, y trabajando en grupo, corrigiéndose unos a otros hay menor probabilidad de equivocarse. Con la segunda me pasa parecido a la primera, ¿que clase de ventaja es esa?, no la entiendo. Las demás tienen un pase, pero, como digo no son realmente ventajas. La que mas me conviencia era “Poder utilizar un proyecto para explorar una nueva tecnología, sin tener que justificar la decisión a otros miembros del equipo o a encargados de proyecto”, y para esto, están los pequeños proyectos de exploración que hace uno personalmente en su casa.