Los fenómenos que se observan en el mundo del software, y en concreto, en lo relativo a la productividad, son a veces sorprendentes.
Tengo una experiencia que me demuestra claramente que la productividad entre persona y persona puede variar en órdenes de magnitud dependiendo sobre todo, creo, del conocimiento y el talento. A diferencia de muchos otros campos, conocimiento y talento (sobre todo este último) son mucho más relevantes incluso, que la motivación. Sea como fuere, las diferencias de productividad son enormes.
En otra escala, sorprende no solo la capacidad de innovación sino también la rapidez y productividad con que pequeñas empresas, a veces núcleos reducidísimos de programadores, son capaces de producir software de extraordinaria calidad, complejidad y funcionalidad y cómo, sin embargo, con frecuencia, las grandes compañías de consultoría, desarrollo o integración son lentas y producen resultados inferiores.
¿Por qué se produce esto? ¿No es contradictorio?
En su libro ‘The mythical man-month‘, Frederick P. Brooks, Jr. analiza este fenómeno y llega a interesantes y clarificadoras conclusiones.
Primero parte del producto típico de ‘garaje’ y es lo que denomina un programa. Dicho programa es autocontenido y se ejecuta en la máquina de su autor y el sistema en que fue desarrollado. En este ámbito es donde suele producirse ese fenómeno de garaje, esa innovación y esa aparente productividad superior.
A partir de aquí, el autor distingue dos ejes en que ese software puede evolucionar
La primera forma de evolución es hacia un producto. Un producto es un un programa que puede ser ejecutado, probado, reparado y extendido por cualquiera. Puede usarse en muchos entornos y con diferentes juegos de datos. Para pasar del programa al producto, se debe producir una generalización, tiene que ser extensivamente probado y debe ser documentado. Esto hace que, en estimación del autor (muy versado en el mundo del software), el producto sea tres veces más costoso que el programa.
La segunda forma de evolución es hacia lo que denomina un sistema. En un sistema los programas interaccionan de una forma coordinada y según una disciplina. Para que el programa pase a ser un componente de un sistema, debe ser escrito de forma que cada entrada y cada salida respete una sintaxis y una semántica precisas. Además, debe hacer un uso limitado de recursos, puesto que éstos son compartidos. Finalmente, debe ser probado en conjunto con el resto de componentes, lo que lleva a la aparición de errores debidos a interacciones insospechadas. De nuevo, el autor estima que un componente de un sistema es, como mínimo, tres veces más costoso que el programa aislado.
Finalmente, podemos mezclar ambas evoluciones para obtener un sistema producto que añade las complejidades de las dos evoluciones anteriores y que proporciona un resultado realmente útil… pero cuesta nueve veces más.
Es cierto que nos estamos fiando de las estimaciones del autor…pero también es cierto que sus argumentos son sólidos y las problemáticas que expresa reconocibles.
Ciertamente, pueden existir otros motivos para la menor productividad en las grandes empresas (burocracia, actividades colaterales no directamente productivas o menor motivación) pero aún así, los argumentos de Brooks parecen dar una buena explicación a por qué es tan costoso pasar de la programación más amateur o tipo startup, a una producción realmente industrial, por qué es tan difícil, en definitiva, pasar del garaje a la factoría.
