¿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í.

22 comentarios sobre “¿Hasta donde podemos llegar?”

  1. Real como la vida misma Rodrigo.

    Ahora cuando para que algo funcione bien debemos dedicarle buen tiempo a ver como estan hechas las cañerias, en vez de meternos con la logica de negocio, pues es que estamos metiendo extra complejidad.

    Si en un proyecto no soy capaz de hacer F10..F10 para llegar tranquilamente al punto mas interno del codigo…. peligro Will Robinson…

    Metemos capas y capas, nuevos sobres y mecanismos de comunicacion, a los cuales el analista debe dedicar mas tiempo que a producir el primer prototipo usable.

    Y si, Sharepoint es potente y cualquier cosas mas, pero menos amigable para el desarrollador, el hecho de que a poco de depurar pierdas la referencia a objetos, que para instalar cosas por fuerza debas hacer un iisreset…

    Cuando me ha tocado, he procurado desarrollar patrones que permitan que mis desarrolladores tengan la vida menos complicada, no siempre lo he logrado, pero ese es el objetivo.

  2. Hola Rodri!

    Estoy de acuerdo contigo en todo lo que has dicho, de hecho ahora, he tenido que hacer un pequeño acceso a datos para una base de datos Sql Server y he tenido que liar el taco con Entity Framework para hacer una simple consulta.

    El software es difícil, y cada vez más monstruoso de grande y además cuando más sabes más problemas tienes y mejor tienes que hacerlo todo, ya no te puedes permitir hacer ñapas como cuando empiezas a programar.

    ¿Y cuál es la solución? Volver hacia atrás, utilizar otro tipo de herramientas más sencillas, ahora programamos más o menos bien en un Thread que va a ser de nosotros en un par de años?, quien va a escribir software concurrente con la rapidez con la que la escribimos ahora, incluso con Task Parallel Library, porque al fin y al cabo es otro framework, nos podemos equivocar igual.

    Saludos desde Londres. Luis.

  3. Así es, la complejidad aumenta y las reglas también, demasiadas reglas, demasiadas tecnologías, ninguna se acaba de asentar completamente cuando desaparece y otra ocupa su lugar. La abstracción está muy bien, hasta que te encuentras con un problema y has de resolverlo.

    Lo que está claro es que los desarrolladores tal y como los conocíamos están en fase de extinción y no me extraña, así que prepararos, los que pasen el corte lograran acceder a un mercado cada vez mejor remunerado, aunque no sé si merecerá la pena.

    Por mi parte, creo, que un día harto de todo esto, volveré a utilizar cobol y me apuntare a alguna entrevista en un Banco o mejor a Iberia que hay sindicatos y ganan más… o quizas me apunte a Gran Hermano, ¿ no se ? …

    Un saludo.

  4. Todo el mundo de acuerdo contigo … pues yo voy a llevarte la contraria :-), por animar un poco el cotarro.

    Empece a programar web con un engendro de servidor propio basado en CGI con Power Builder. Para escribir la salida tenias que manejar los string a nivel de bytes! No voy a hablar de manejar header, cookies … y AJAX!

    ¡Una semana picando código para el mantenimiento de provincias!

    Hoy trabajo con ASP.NET y de verdad la productividad está a años luz!
    Tenemos herramientas más potentes y se nos exigen aplicaciones mas potentes.

    Tienes razon cuando hablas de que la complejidad cada vez es mayor, tenemos que manejar mas y mas tecnologias y en ocasiones nos sentimos desbordados … pero somos espartanos! y en el fondo creo que a todos nos gusta la guerra (aunque un poco de paz de vez en cuando tampoco viene mal).

    Saludos,
    Pedro

  5. Aupa Rodri.

    Totalmente de acuerdo pero aun tenemos un handicap sengun mi punto de vista. Esa complejidad que va en aumento la vemos tu,yo y un monton de gente mas. Pero en todas las empresas existen estamentos que no ven esa complejidad. Cunado vas al jefe y le pides personal con solvencia obtienes la mitica respuesta «reciclemos a los que tenemos que en dos dias se ponen las pilas con eso del VB de .Net total es igual que el viejo Visual Basic». Asi luego nos rondan los buitres en algunos proyectos.

    Resumiendo que los frentes aumentan; tenemos la complejidad creciente, esos jefes que no ven o no quieren ver que día a día las cosas son mas complicadas y el personal sin experiencia y/o conocimiento.

    Ponlo todo en una coteclera y tendras un bonito coctel Molotov.

    A mi solo me queda resignarme y seguir estudianto, investigando para seguir en el filo, que cruz de profesión!!!!

  6. Hombre, en la línea de lo que apunta Pedro, es cierto que cada vez somos capaces de hacer cosas más complejas con menos esfuerzo. ¿Alguien se imagina hacer web services con VB 6?, posible es pero a que coste… sin duda hacer AJAX a manopla no es ni parecido a hacerlo usando una librería adecuada y así un largo etc… pero el punto es que ninguno de estos avances dejan de ser ‘máximos locales’, yo hablo de que es necesario un nuevo paradigma que mejore nuestra productividad de manera radical, no que mejore algunas de las actividades.

    Cuanta razón tiene Miguel en lo que apunta. Hay gente que sigue pensando que hacer un sistema distribuido, por poner un ejemplo, con miles de usuarios concurrentes es ‘trasparente’ por que existe WCF… con WCF es un problema de una complejidad increible.

    Luis, no creo que nos hartemos. Tenemos por delante los trabajos de Sisifo, pero no dejamos de ser Sisifos felices con lo que hacemos. Eso si, la gente que está en esto solo para ganarse la vida, que no ama esta profesión, lo tiene muy muy jodido.

  7. Mira, yo llevo un año y pico migrando a .Net, toda la vida (5años) con Java y ahora debo olvidar todo y empezar de cero; yo con lo que me encuentro no es solo con proyectos complejos, me encuentro que las herramientas que uso para hacer esos proyectos cada vez tambien son más complejas; VS08 es un mundo en sí, SqlServer otro tanto, c# es más y más extenso, luego wcf, wpf, wf, Ent.library, scsf, wcsf,…; no sé pero me cuesta muuuuuuuuuuucho seguir esto.

    :-/

  8. Rodri!!!!!!!!!!!!!!!! ¡Qué razón tienes, joío!

    De todos modos, yo no soy pesimista. Yo soy optimista. No creo en la complejidad per sé, creo en la complejidad artificialmente creada, que es en lo que estamos. Ya sé que productos como Visual Studio o Windows Vista son complejos, muy complejos, pero son complejos artificialmente por las interfaces fuertemente acopladas que tienen. Y lo mismo pasa con otros productos. Querer mezclar churras con merinas (el mismo asistente para C++ que para C# que para VB.NET, por poner un ejemplo evidente por sí mismo). ¿Qué hay de malo en que haya un ejecutable para C++, otro para C# y lo mismo para VB.NET?

    Encima hay otro problema añadido a la complejidad: los productos salen sin terminar, con miles y miles de bugs que cuando se producen en nuestras aplicaciones nos hacen dudar de quién lo está haciendo mal (sí, ya sé que es de uno mismo de quien hay que dudar en primer lugar, pero a veces…).

    Añade las interfaces fuertemente acopladas, cuando haces clic en el reloj de la barra de tareas se corta internet, por poner un ejemplo que no es cierto…

    Cada uno habla sobre cómo le llueve, en mi caso he manejado programas hechos por mi mismo de unas 100.000 líneas de código y cuando ha salido algún problema inmediatamente he sabido en qué módulo, y hasta casi en qué función se ha producido… claro que yo siempre acoplo débilmente las distintas partes de mis programas (La idea es como el paso entre anillo 0 y anillo 3: sólo hay una puerta, fuertmente protegida a ambos lados…)

  9. Bajo mi punto de vista, no se trata de una cuestión de optimismo o pesimismo, sino de mera ciencia:

    Opino que deberíamos estudiar este fenómeno según las leyes de la termodinámica: El «volumen» del software que necesitamos es equivalente al volumen de un gas, que siempre se expande hasta ocupar todo el espacio disponible, adoptando la forma que le marca su recipiente.

    Por eso, mientras la ley de moore nos ha asegurado mejoras exponenciales en la capacidad de cómputo del hardware, de la misma manera ha aumentado también el «volumen» del software que «necesitábamos».

    Y en la medida en que la ley de moore dé síntomas de agotamiento, necesariamente tendrá que moderarse el aumento desenfrenado de la complejidad del software que necesitamos.

    Simplemente recordar que en los años 70 Bill Gates escribió un intérprete de BASIC que ocupaba 6 Kb (el mismo Bill Gates responsable de que hoy un simple programa de «Hello World» ocupe centenares de Kb en .NET)

  10. @galcet: no creo que sea un problema de lenguajes o plataformas. Es igual de arduo hacer software en Linux que en Win y en Java que en .NET. No siquiera Python o Ruby han supuesto un cambio espectacular a pesar de que era uno de sus objetivos.

    @Rafa: Da igual lo que hagas, tu no eres 100 veces más productivo que antes. Y el software si es 100 veces más complejo. Cierto es que los productos cada vez parecen menos acabados, todos, otra manifestación de esa complejidad.

    @cgr: ¡me ha encantado el simil!.

  11. A ver que entendemos por «productividad», porque me parece a mi que lo que esta palabrota quiere decir es algo así como «lo que antes era complejo ahora lo haces más rápidamente, pero lo que hoy es complejo te sacará canas verdes».

    Por ejemplo, cuando empecé a trabajar hace unos añazos, estaba en una empresa donde creábamos un software enlatado que era un BPM y como no existía BTS, Sharepoint, etc. nos picábamos todo a mano: el motor de Workflow, el portal en ASP + Componentes COM+, la gestión de usuarios (no quiero recordad el infierno de AD con NT 4), los componentes de integración, etc. Hoy hacer esto mismo seguramente es mucho más simple, es como un LEGO: seleccionas los componentes adecuados y los ensamblas; pero claro este tipo de aplicaciones hoy son de las «fáciles». Las difíciles son las que planteas los escenarios que tu comentas 😀

    Y eso que no me meto con la gestión de los equipos de trabajo, que sino no no terminamos más.

    Saludos y nice post

  12. Pues entonces habrá que ver si realmente necesitamos esa complejidad, en base al ejemplo que has puesto, a lo mejor debemos volver a las aburridas cajitas, si estas hacian su función puede ser que no sea preciso complicar más la cosa en tanto en cuanto el resultado sea el mismo (ver los valores de funcionamiento de los aparatos monotorizados).

    Y sinceramente, si a alguien como tú se siente pesimista en la evolución del sw, entonces mentes menos privilegiadas como la mia mejor lo dejamos ahora que aún estoy a tiempo de empezar en otra cosa… (siempre me gusto la carpinteria).

    agur!

  13. Ummm… Jorge, tienes razón. ‘No hay balas de plata’ es de Brooks, corregido en el artículo, gracias por el apunte. El resto de citas con correctas.

    He añadido también una cita explicita a No silver bullet, una de las inspiraciones de este artículo, pero no la única.

    Un saludo.

  14. Evidentemente las funciones del software son las mismas ahora que hace 10 años(como por ejemplo, sacar los datos de una base de datos y mostrarlos en un monitor), pero los requisitos han cambiado (yo creo que esa es la clave), el software ahora controla procesos de fabricación mas sensibles, el nivel de tolerancia al fallo tampoco es el mismo (antes eran normales pantallazos azules, ahora pones el grito en el cielo), las necesidades de escalabilidad y reusabilidad no son las mismas, el nivel de seguridad, la accesibilidad, los interfaces de usuario, la multitarea, … Porque ahora además de mostrar datos en un monitor, hay que presentar un informe con los datos, exportarlo a PDF, JPG, Excel y rtf…, Además tiene que tener la lógica de negocio publicada mediante servicios Web, integrarse con un gestor documental, actualizar los datos de 4 gestores de bases de datos diferentes, mostrar los datos en una PDA y en un Spectrum… ¡¡¡nada es lo mismo!!! Bueno! los bucles, los condicionales y la declaración de variables, apenas ha cambiado… pero evidentemente la manera de hacerlo funcionar no es la misma, ahora tenemos arquitecturas en capas, programación modular, orientada a Objetos, orientada a Aspectos, orientada a Servicios, …

    Es un estracto de algo que escribí hace tiempo:

    http://geeks.ms/blogs/msierra/archive/2008/08/20/161-algo-est-225-cambiando-en-el-desarrollo-de-software.aspx

  15. El software es cada vez más complejo porque los clientes quieren cada vez más.
    Hace años hacías unos forms en Access con cuatro botones y dos informes y le enseñabas el funcionamiento al listo del departamento. Ahora no. Ahora (y esto es un caso real) tenemos un cliente que quiere recibir cada día 4 informes con las ventas del día anterior en su negocio y hemos tenido que crear un Emailer automatizado para él. Y los informes no son en texto, son pdf adjuntos con un cuerpo del mensaje creado con una plantilla. Si a eso le añadimos que hay que saber C#, SQL Server 2005, Crystal Reports y dos o tres cosas más al dedillo para que el trabajo no esté lleno de bugs (y aprender requiere tiempo) no me extraña que muchos proyectos fracasen

  16. Odio ir de pedante y comentar sólo para corregir algo, pero me temo que la ley que atribuyes a Boehm en realidad es de Brooks, en su libro «The Mythical Man-month». Ahora me debes una corrección a mí 😉

  17. Ah, bueno, y que por lo demás, un interesante post, que he marcado para releer. el tema de la complejidad del software es uno de especial interés para mí.

  18. Todos vuestros razonamientos me llevan al desanimo de tantos años dedicados.

    Me estoy acordando del programa de Eduardo Punset de este domingo

    http://www.smartplanet.es/redesblog/

    me quedo con la idea: en un hormiguero no hay ningun elemento de la comunidad mas listo que los demas, ni nadie que mande ni gobierne, pero que gracias a la suma de las pequeñas interaciones de todas las hormigas logran embargarse en proyectos de gran amplitud e impensables y llevarlos a cabo.

    Quiero ser una hormiguita y solo preocuparme de interactuar con las 4 hormiguitas de al lado!!!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *