«De muchas formas, dirigir un gran proyecto de programación es como dirigir cualquier otra gran empresa – de más formas de las que la mayoría de programadores piensa. Pero de otras muchas formas es diferente – de más formas de las que la mayoría de gestores profesionales esperan»

Así comenzaba en 1975 Frederick Brooks su libro «El mítico hombre-mes», una obra que se ha convertido en un clásico de la gestión de proyectos informáticos. Sin embargo, 40 años después, cuando la informática ha pasado de estar encerrada en laboratorios de Universidades y centros de datos en bancos a ser una realidad cotidiana para miles de millones de usuarios, no parece que sus acertadas observaciones hayan sido aceptadas por más que una minoría de profesionales del sector.

Seguimos viendo proyectos faraónicos que fallan estrepitosamente por un diseño, planificación y ejecución deficientes más que por falta de recursos. En el mejor de los casos, se llevan a término con significativos retrasos, exceso de costes y falta de funcionalidad. Y lo peor de todo es que estas situaciones se podrían haber evitado si los gestores conociesen a fondo las peculiaridades del desarrollo de software. No se puede dirigir un proyecto informático de la misma forma que la construcción de un edificio o una fábrica de embutidos, aunque hoy en día parece extenderse la idea de que quien es experto en gestión, puede gestionar cualquier actividad con tal de rodearse de especialistas. Es esa mentalidad la que da munición a Dilbert para sacar miles de tiras cómicas, aunque para los desarrolladores que se ven implicados en determinados proyectos es cualquier cosa menos divertido.

La ley de Brooks

Es la tesis central de la obra, y su enunciado dice que «añadir gente a un proyecto que va retrasado lo retrasa aún más». Para muchos gestores, esto es completamente contraintuitivo. Lo lógico sería que si un programador tiene una productividad X, diez programadores producirán 10·x, y en consecuencia, el proyecto se acabará en la décima parte de tiempo. Pues va a ser que no.

La clave está en que la programación, o el desarrollo de software en general, es una actividad intensiva en conocimiento. La productividad de cada miembro del equipo depende exclusivamente de lo que tiene en su cabeza. Y cuando se contrata a un nuevo desarrollador, aunque tenga una gran experiencia en otros campos y sea experto en el manejo de varios lenguajes y herramientas, aún no tiene lo que se llama el conocimiento del dominio (domain knowledge): No sabe nada del proyecto concreto en el que se integra, y asimilar toda esa información puede ser mucho más difícil que dominar un lenguaje de programación.
Además, la documentación no suele ser una prioridad. Si la hay, no está actualizada, no se lee, o ambas cosas, y finalmente siempre se recurre a la tradición oral, lo que obliga a preguntar constantemente a otros miembros del equipo -los más expertos-, quienes acaban dedicando más tiempo a formar a los novatos que al desarrollo propiamente dicho.
Las empresas mejor organizadas tienen estos aspectos sistematizados proporcionando un curriculum de formación específica a los nuevos empleados, aunque en la práctica esto es poco común. De hecho, cuando hace años entré a trabajar en Lucent Technologies (hoy Alcatel-Lucent), los tres primeros meses los pasé exclusivamente asistiendo a cursos de formación en las herramientas y procesos de la empresa, antes de poder tocar una sola línea de código «real».

El factor humano

Podemos explicar un poco más a fondo la evolución de la productividad en función del número de integrantes del equipo: El número de caminos de comunicación crece exponencialmente con el número de miembros. Con dos programadores, basta con que se comuniquen entre ellos y tenemos sólo un camino. Pero si por ejemplo son diez, el número de posibles vías de comunicación crece hasta n(n-1)/2, es decir, 45.

Y este es el hecho que sugirió a Brooks la idea central de su libro: la posibilidad de medir el esfuerzo necesario para desarrollar un proyecto en «hombres/mes» es, pura y simplemente, un mito. Un mito que tiene su origen en tratar de aplicar el paradigma industrial a una actividad que no es de producción, sino diseño y creatividad. A pesar de muchos intentos, el desarrollo de software no se deja sistematizar de forma apreciable, y el trabajo de un programador es más parecido al de un arquitecto, un diseñador o un escritor. O una mezcla de los tres, sobre todo del último, ya que a fin de cuentas, programar es escribir. Para una máquina, pero escribir.

¿Listos para subir al siguiente nivel?

Cuando la tarea consiste en diseñar la arquitectura de una solución compleja y planificar su implementación, no basta con saber elaborar diagramas de Gantt. Es necesario conocer las tecnologías disponibles (cada vez hay más) para seleccionar las más adecuadas, y en función de las mismas realizar un diseño para luego dividirlo en unidades que puedan ser implementadas de forma más o menos independiente por los diferentes equipos o programadores. Muchas veces, a los clientes o usuarios finales les resulta difícil saber qué están haciendo esas personas que pasan horas y horas delante de una pantalla tecleando palabras ininteligibles para un humano corriente. Sin embargo, detrás de esos miles de líneas de código hay una estructura, un «mundo» virtual que tiene una organización (buena o mala) y es lo que permite que finalmente una aplicación funcione. Resulta muy interesante visualizar una aplicación medianamente compleja con herramientas como CodeCity, y ver el orden que hay tras un desarrollo. En las empresas más avanzadas ya es común -y muy importante- el puesto de arquitecto de software: una persona que tiene un profundo conocimiento de las tecnologías a utilizar; sabe qué tipos de componentes se pueden integrar entre sí, y evaluar el trabajo necesario para hacerlo. Diseñar las interfaces entre los distintos subsistemas, y planificar el desarrollo adecuadamente. Como vemos es una labor que va bastante más allá de lo que en muchos casos se simplifica como «programador».

El equipo quirúrgico

Otra de las tesis de Brooks es que los equipos de desarrollo más eficientes son los que tienen una estructura similar a los que operan en un quirófano: un desarrollador experto ( el lead developer) y un equipo que le ayuda en las tareas auxiliares. De hecho, Brooks sostiene que en el campo de la programación puede haber unas diferencias de productividad de hasta 10 a 1 entre unos desarrolladores y otros. Y no hay más que ver cómo las grandes obras de software han surgido de esta forma. La primera versión de Linux fue desarrollada por Linux Torvalds cuando tenía 21 años. UNIX y el lenguaje C fueron obra de un reducido equipo capitaneado por Kernighan, Ritchie y Thompson. Más recientemente, Drupal surgió de los dedos de Dries Buytaert en su habitación de residencia de estudiantes. Y Google comenzó su meteórico ascenso cuando desplazó a los entonces dominantes AltaVista y Yahoo gracias a su revolucionario algoritmo, obra de Sergei Brin. Por supuesto, todos estos proyectos han incorporado posteriormente innumerables contribuciones, pero el hecho de que hayan podido expandirse de esa forma es debido a que en su origen su arquitectura es nada menos que genial.

El estado de la cuestión

Todavía hay muchas perlas en este libro, cada una de las cuales merecería un post por sí misma y que siguen siendo tan actuales como el día en que se escribieron. Y sin embargo, a pesar de la importancia que tiene la informática hoy en día y la proliferación de herramientas, lenguajes de programación y metodologías de desarrollo, seguimos observando las mismas patologías que hace décadas. Casi siempre debidas a causas fácilmente evitables que se pueden resumir en una generalizada falta de comprensión de la idiosincrasia del desarrollo de software por parte de quienes están al cargo. Probablemente nos llevaríamos las manos a la cabeza si contabilizásemos los miles de millones que se han ido a la basura por este motivo. Si Brooks quisiese escribir hoy una edición actualizada de «El mítico hombre-mes», tendría material más que suficiente para varios tomos.