De un tiempo a esta parte se ha oye el concepto de "programación colaborativa" entre varios programadores de forma que varios programadores trabajen simultaneamente sobre el mismo fragmento (o fragmentos) de código.

La idea detrás del paradigma consiste en que dos pares de ojos ven mucho más que uno y por tanto, aunque la productitividad de dos programadores trabajando será siempre mucho menor que la productividad de ambos por separado, la calidad del código producido será muchisimo mayor, lo cual debería llevar a un código más mantenible, más organizado, más elegante y más seguro.

Efectivamente cuando dos programadores trabajan sobre el mismo código, especialmente si lo hacen uno al lado del otro sobre el mismo monitor, el código resultante es mucho mejor. Todo programador tiende a cuestionar lo que hacen los demás. Un profesor mío lo llamó el sindrome NIH (not invented here, no inventado aqui) que nos impulsa a rehacer cosas que ya están perfectamente hechas y pensadas pero que no hemos hecho nosotros. Esto hace que para cada idea que uno de ellos tiene el otro la examine desde todos los ángulos pero, puesto que el resultado final es producto también de ambos programadores, cada uno de ellos puede sentirse orgulloso del código que han hecho entre ambos.

Así que realmente la pregunta que nos queda por hacer es, ¿merece la pena gastar el doble de dinero en producir un código un 50% mejor?

En realidad la pregunta, si nos ponemos pragmáticos, tiene una respuesta muy sencilla. No importa. Ningún manager, jefe, gerente... resumiendo ningún jefe de managment va a poner a dos programadores a hacer el trabajo de uno, por lo que la pregunta es meramente hipotética, nunca he oido hablar de ningún proyecto en el que se de tal modelo de trabajo.

Parte del problema viene del hecho de la concepción del software que tiene la gente de managment e incluso la gente que ha estado alejada del código por un tiempo considerable. Para ellos construir un sistema software es como levantar un edificio (una concepción que nosotros mismos hemos causado comparandonos demasiado amenudo con arquitectos), por lo que solo hace falta un tío que diseñe los planos uno o a lo sumo dos jefes de obra y cuarenta tíos poniendo ladrillos, que tampoco importa si son expertos ponedores de ladrillos, el trabajo difícil es el del arquitecto ¿no?... Pues no

En primer lugar hay una serie de diferencias entre el software y la construcción pero quizá la más fundamental es que la arquitectura tiene, pongamos, unos 10.000 años y hace 5.000 se construyeron las piramides que son, sin duda, una de las construcciones más asombrosas y una de las siete maravillas. Nosotros, por seguir con el simil, empezamos a construir casetas de paja hace unos 60 años, viaductos y acueductos hace 30 y ahora mismo intentamos construir rascacielos.

Por otro lado, por mucho que gusten las comparaciones el código no son ladrillos y construir una aplicación no puede compararse con ir apiñando y uniendo fragmentos de código de aqui y de allá e ir uniendolos con argamasa sino que cada fragmento de código es distinto, es importante que esté bien hecho y es importante que todo se una bien y siga una determinada "arquitectura". Yo nunca he sido partidario de decir que cualquiera puede tirar lineas de código.

Pero volviendo al tema, como decía, dos programadores por puesto es irrealista e incluso contraproducente desde el punto de vista del negocio. No hay por qué ser iluso, el objetivo (en su mayor parte) de una aplicación es ganar dinero y por tanto no tiene por qué ser perfecta, bastará con que sea lo suficientemente buena como para ganarle dinero. Una aplicación puede ser una obra de arte, casi perfecta en todos los sentidos, pero si hemos tenido que gastar el doble en conseguirlo quizá no podamos amortizarla, quizá incluso no podamos construirla porque se nos acabe el dinero.

Donde son necesarios dos, y tres y los que haga falta, es en el diseño de la arquitectura. Personalmente no dejaría nunca que una sola persona decidiera por si misma la arquitectura completa de una aplicación. Pero no porque no sea factible, que sin duda lo es, sino porque, comparada con la implementación, es una fase relativamente corta donde una buena inversión en producir algo de mucha calidad redundará en una mejora en todas las partes de la aplicación (de paso esto que estoy diciendo no es nada nuevo).

Además, por bueno que sea un programador, por brillante que sea, siempre hay puntos flacos, cosas que no se te ocurren o que, llegado el caso, se te ocurren un tiempo después, cuando entras en materia, mientras que si hay varias personas muchas de esas ideas olvidadas saldrán a la luz mucho antes.

Por tanto en un mundo perfecto el asunto de la "programación colaborativa" sería ideal. Varios programadores producirían un código con una calidad superior a lo normal, evitaríamos muchos problemas de seguridad o errores tontos (yo alguna vez he programado en "grupo" sobre el mismo código y puedo asegurar que los errores de código, ya sean de concepto o de sintaxis se ven muchisimo más rápido, como un 90% más) y el código sería muchisimo más mantenible y elegante. Pero por desgracia no estamos en un mundo perfecto y lo cierto es que, aunque las discusiones filosóficas son interesantes, dos programadores rinden más en códigos separados de lo que lo hacen en el mismo y el impacto de mantenibilidad no es, para mi, suficientemente grande como para justificarlo. Dos programadores mediocres producirán un código solo un poco menos mediocre (si es que no se perjudican el uno al otro para crear verdadera basura), dos programadores brillantes tampoco se beneficiarán en exceso puesto que las mentes brillantes tienden a pensar igual. Evidentmente si antes cometían 50 errores por cada 1000 lineas de código quizá ahora solo cometan 10, pero de nuevo, no es suficiente para justificarlo.