¿Hasta donde podemos llegar?

ComplejidadUn anuncio de Microsoft decia: ‘hasta donde quieres llegar hoy’ o algo así, pero la pregunta es más bien ¿hasta donde puede llegar la ingeniería del software?. Comenta Gustavo, vecino de blog y uno de los grandes de Sharepoint (y no solo de Sharepoint) que cada vez la complejidad de los proyectos de Sharepoint es mayor, tanto como para que en muchas ocasiones lo mejor sea esconder la cabeza como un avestruz.  Yo lo se bien, pase de conocer a fondo la versión 2003 a caer en la sima de la transición a 2007. Hace tiempo que deje de ser un experto en Sharepoint, si es que alguna vez lo fui del todo, el salto a la versión 2007 me supero, demasiada complejidad para un humano mortal.

En mi opinión lo que Gustavo comenta no solo está ocurriendo en Sharepoint. Es un problema generalizado, cada vez más voces importantes del mundo de la ingeniería de software se preguntan si no hemos alcanzado un punto de singularidad en el que la complejidad de los problemas a resolver se ha incrementado más allá de lo manejable.

Hace poco veía un proyecto que han hecho una compañeros de Plain Concepts. La interfaz es realmente acojonante, lo que antes serían aburridas cajitas de texto y etiquetas ahora son preciosos controles de WPF que informan visualmente del estado de los aparatos que la aplicación monitoriza. Se cae la baba viendo la interfaz. Pero eso tiene un precio. Hay miles de líneas de WPF y XAML. ¡Miles de líneas en la interfaz de usuario!. Se que muchas son generadas, pero me da igual, generadas o no son fuente de complejidad. La herramienta las genera, pero tu las mantienes y cuando la herramienta falla o la abstracción fuga, el problema es tuyo. Más código más problemas.

Los sistemas son cada vez más complejos, exponencialmente más complejos, pero las herramientas han cambiado solo sutilmente. Ya nos sabemos eso de KISS, si, pero no es suficiente. En esencia, desde que Grace Murray, almirante de la marina estadounidense y probablemente la mujer más influyente en la historia de la ingeniería de software, invento el compilador, no se ha producido un cambio cualitativo importante en la forma en que se hace software. Codificar, compilar, depurar. Solo se han añadido billones de horas hombre al desarrollo de software. Fuerza bruta. El problema es hasta donde escala esta aproximación… cada vez parece más que hemos tocado techo. Hay quien incluso ha puesto nombre a este problema: el dilema de la divergencia del software. Ahí es nada…

Para que os hagáis una idea. Un avión de caza de los años 60, tenía típicamente unas cincuenta mil líneas de código, un caza moderno unos cinco millones de líneas de código. Cada vez me da más por los aviones para hablar de software :). En este periodo, pese a la evolución de las herramientas, los estudios más optimistas sostiene que se ha doblado la productividad de los desarrolladores. Y mucha de esa productividad se ha ido en actividades de coordinación entre los miembros el equipo.

Barry Boehm, padre del modelo COCOMO y padre del ciclo de vida en espiral, comentaba en 2004, en un conferencia auspiciada por el DoD (Department of Defence, el mayor contratista de software del mundo por mucho), que ‘la cantidad de software que el DoD necesita crece exponencialmente, por lo tanto nunca podremos completarlo en un tiempo finito de tiempo’, para echarse a llorar… o no, también se puede hacer la lectura positiva: los informáticos tenemos una cantidad de trabajo infinita por hacer.

Yo personalmente soy pesimista. Todos los intentos de atajar la complejidad que hemos realizado han sido en vano. Los patrones parecían prometedores, pero aunque útiles no han supuesto una revolución. Las herramientas 4GL se postularon como una especie de bálsamo de Saxafrax, que se quedo en nada ¿alguien usa 4GL?. Las herramientas de modelado… en fin… esperemos a Oslo, pero mucho me temo que tampoco será mágico… y necesitamos mucha magia. Las herramientas no van a ser la solución al problema. Fijaros, llevo programando desde VB3.0. En la caja de todas la herramientas de programación que he usado desde entonces ponía algo parecido a ‘mejora tu productividad un X%, siendo X > 20’. He conocido VB4, VB5, VS6, VS2001 (productividad con esteroides gracias a .NET), VS2003… hasta VS2010. Si cada versión hubiese mejorado mi productividad lo que su marketing prometía ahora yo sería capaz de programar con la mente.

En el lado de los procesos de desarrollo, me conformo no ya con ganar productividad, sino simplemente con poner orden en el caos que se contempla en la gran mayoría de los equipos de desarrollo. Mejoras lo que se dice mejoras, se ven, pero no radicales no nos engañemos.

Ahora todos los proyectos dan miedo, mucho miedo, no hay proyectos sencillos. No los hay. Aun recuerdo cuando, en mi época de freelance, yo, con veinte añitos recién cumplidos era el rey del mambo: ¡sabia que existían los módulos de clase, sabía que existía DCOM y como hablar con SQL Server!, estaba a años luz del programador medio. Ahora todos los proyectos dan miedo. Hay unas frase de Linus Tordvals que son esclarecedoras: ‘No esperes hace nada grande en poco tiempo’ dijo, ‘he estado trabajado en Linux trece años, y creo que lo hare durante bastante tiempo más. Si hubiese pensando que me estaba metiendo en algo tan grande, nunca hubiese empezado’. Esclarecedor. Hay que tener un punto de incauto para meternos en los proyectos que nos metemos.

El tema se resume en dos frases, una de Donal Knuth: ‘hacer software es difícil’ y otra de Fred Brooks: ‘no hay balas de plata’ que da título a uno de los grandes ensayos de la historia de la ingeniería del software. Brooks es también el padre de la ley que lleva su nombre y que dice que ‘añadir desarrolladores a un proyecto retasado solo lo retrasa más’, luego extrapolando esta ley, añadir más fuerza de desarrollo no va a arreglar el problema como ya he comentado. 

La paradoja es que dificultad es tal que necesitamos unas balas de plata que no tenemos en nuestra arsenal. Unamos a esto que la ley de Moore ya no está ahí para salvarnos el culo permitiéndonos cambiar complejidad por ciclos de reloj. Tenemos una tormenta perfecta. ¡Hemos llegado al límite!.

¿Sois vosotros igual de pesimistas que yo? Gustavo creo que sí.