Nos encanta que nos mientan

A los desarrolladores, ingenieros de software, analistas, etc. nos encanta que nos mientan. Luego de pensar por mucho tiempo y observar la conducta de mis pares durante algunos años y observando la reciente historia del desarrollo de software llego a ese inequívoca conclusión.
¿Por qué pienso esto? Para explicarlo me voy a ayudar con términos gráficos usando una burda línea del tiempo:

La imagen superior muestra una improvisada reseña de algunas tecnologías recientes que se me vinieron a la mente - incluye un poco de todo, lenguajes, frameworks, librerías, etc. - y lo dibuje rápidamente con Inkscape :-).
No me critiquen los errores, ni la escala, ni el diseño gráfico inexistente, es algo aproximado, pero escucho sugerencias de cambios o cosas que me haya olvidado.

Lo interesante es notar como en relativamente poco tiempo - 1990 a 2008 son 18 años - han pasado tantas tecnologías y herramientas que en definitiva sirven para lo mismo, hacen lo mismo, y lo que es peor nos venden los mismos fabricantes. Si usted es un joven y no conoce mucho de la historia reciente del desarrollo de software le recomiendo que investigue un poco para poder visualizar la cantidad de herramientas que hemos tenido que aprender quienes estamos en esto de la programación desde hace más de una década. De todas formas si todavía no sufrió el paso de una tecnología propietaria o "abierta" a otra "nueva" que hace lo mismo "pero es mejor" seguramente lo sufrirá próximamente.
Cuando se pasa por la situación de tener que reescribir nuestro software en varias plataformas, lenguajes, runtimes, pero que en definitiva ES LO MISMO, podemos tener dos reacciones: sentimos una profunda desesperación y llegamos a percibir lo precaria e involucionada de nuestra profesión, o nos ocurre lo contrario y reescribimos nuestros repetidos programas encantados de hacer lo mismo una y otra vez con cada "cosa nueva".

Es entendible que las personas jóvenes, quienes estan hace poco tiempo en esto del software, se inclinen por la resignación o se vean sorprendidos cuando don microsoft (si con minúscula) les dice lo lindo que es .NET y como es mejor que todo lo anterior, o aplaudan a un "evangelizador" java cuando en una conferencia les cuenta lo hermoso de hacer programas SOA con java (si también con minúscula) y como perdieron el tiempo si habían desarrollado demasiadas cosas con EJB 2.0 usando algún ORB CORBA porque en definitiva ahora eso no es necesario. Lo que quiero decir es que entiendo que quienes tenemos menos experiencia - y me incluyo - nos creamos muchas veces esta dialéctica del "avance tecnológico" de las grandes empresas proveedoras de software de base y middleware.
Pero lo que no entiendo - o si lamentablemente - es que profesionales con muchos años de experiencia, con muchas tecnologías y lenguajes de programación en su espalda se lo sigan creyendo o al menos sigan realizando software sin importarles que lo que hoy estan escribiendo lo deberán tirar a la basura en un par de años cuando el framework de moda lo reemplaze.

Gustave Eiffel, famoso ingeniero estructural frances, diseño junto a Emile Nouguier y Maurice Koechlin - principales ingenieros en Gustave Eiffel & Cia. - su aún más famosa torre Eiffel hace poco más de 120 años. Planeada desde 1884 y rechazada para ser construida en la feria mundial de 1888 en Barcelona se termino construyendo para la feria mundial de 1889 en Paris.
Proyectada inicialmente para durar 20 años la torre se volvió inmensamente popular recibiendo hasta la actualidad más de 236.000.000 de visitantes. Antes de su inauguración y durante su construcción recibió numerosas criticas de diversos artistas y personalidades, miedos de que la torre se cayera y causara un desastre, criticas a su "fealdad" y a su "desnudez".
Durante el dominio Alemán de Paris en la segunda guerra Hitler mando a desmantelarla, cuando los aliados se acercaban a la recuperación de la ciudad, pero el oficial a cargo ignoro la orden afortunadamente. Su principal mantenimiento es ser repintada cada siete años.
Eiffel explicaba a los críticos iniciales de la torre que su forma y apariencia "desnuda" era resultado de las matemáticas e ingeniería aplicada en el diseño para garantizar que la torre no se cayera sobre su propio peso, y más importante resistiera los embistes del viento. La ingeniería debía aplicarse para lograr construcciones solidas y duraderas.

Lo de la torre es uno de tantos ejemplos en la ingeniería civil que se pueden encontrar para mostrar que en dicha disciplina "tener ingenio" y realizar construcciones durables, solidas y confiables, es posible.
Tal vez no es justo comparar la ingeniería estructural con la ingeniería de software, pero si ambas son ingenierías pienso que es valido comparar salvando las distancias, y pienso que es valido esperar que un día la ingeniería de software alcance y supere en sus construcciones la durabilidad y solidez en la ingeniería civil.
En los puentes, las torres, los edificios son las fuerzas de la naturaleza los que limitan la duración de una construcción.
En la ingeniería de software nuestro producto corre sobre nuestro propio mundo, en nuestro propio universo hecho a medida, dinámico como el mundo real, pero diseñado y construido por nosotros. En la ingeniería de software no existen huracanes, tornados, terremotos, erosión, gravedad terrestre, fatiga de materiales. Entonces deberíamos de preguntarnos que es lo que hace que el producto de nuestro trabajo sea tan poco solido, tan poco perdurable cuando en realidad contamos con un entorno "controlado" y diseñado por nosotros mismos - al menos por nuestros pares - y aún así el software que construimos es en general patéticamente frágil y perecedero. Difícilmente algún ingeniero de software hoy en día se anime a garantizar la durabilidad de un software por más de diez años, situación que encuentro muy graciosa teniendo en cuenta que el software es una abstracción y por tanto deberíamos de poder garantizar su durabilidad por lo menos por un par de siglos.

Sin lugar a dudas, los ridículos resultados de la ingeniería de software tienen muchas causas y pasar de la prehistoria actual a la modernidad nos llevará un tiempo y se requerirá un cambio cultural y técnico muy importante. Pero debemos empezar a trabajar ya mismo para lograr ese cambio en las generaciones que vendrán. Hoy en día aunque existiera un Gustave Eiffel de la ingeniería de software no podría construir su torre por que sencillamente no contaría con los medios técnicos para realizarlo aunque poseyera el ingenio y la creatividad necesaria.

Para comprender más lo precaria de nuestra situación basta con observar en las universidades - al menos las argentinas que son las que conozco, y entiendo no estan muy alejadas de las del resto del mundo - las carreras de sistemas. En mi querida UTN regional Córdoba, para poner un ejemplo, prácticamente sólo se enseña java y algo de .net, sólo el proceso unificado y el paradigma de orientación a objetos. Los alumnos luchan para hacer estúpidos ABMs de forma artesanal tal como un troglodita armaría una choza detrás de otra a mano porque no conoce ninguna técnica más avanzada ni cuenta con ninguna otra maquinaria o herramienta más que solo un destornillador.
En esa misma universidad un profesor de probablemente la materia donde más programación se ve en toda la carrera implementa un algoritmo de archivos en java usando: "longitudIndice = cantidad * 8" donde "8" es la cantidad de bytes en un tipo de datos "long" en java. Querido!! el long en java mide 8 bytes porque la JVM actual es de 32 bits, cuando se pase a una JVM de 64 bits ese software ya no funciona más.

Nota: como me han hecho notar sabiamente mi ignorancia con la JVM 64bits, el ejemplo es incorrecto porque en la JVM actual de 64bits el long también posee 64bits -me temo que segui el pensamiento logico de pensar que en una plataforma de 64bits un "int" sería del tamaño de palabra de la plataforma es decir 64bits y por tanto el long debería ser de 128bits, estoy pensando que es más confuso que tener "long" que no son "long" :-). Esto no es así en la JVM de 64bits actual, lo cual no invalida de todas formas el ejemplo. Hardcodear un tamaño de tipo nativo en código que va a manejar archivos sigue siendo errado - mi humilde oponión es que lo correcto es poner "Long.SIZE / 8" a falta de un "sizeof" y teniendo en cuenta que el miembro SIZE en java devuelve la cantidad de bits lo cual ya si es indivisible e independiente de la plataforma de igual forma que el valor 8 que en este caso es el tamaño de un byte lo cual si es universal, pero de todas formas lo ideal sería que el lenguaje proporcionara un sizeof - desde el punto de vista de generar software multiplataforma y de larga duración, el punto del ejemplo sigue siendo el mismo, simplemente aceptamos la fragilidad del software y el alto acoplamiento con un runtime y plataforma en particular, ni lo pensamos, ni nos importa. Es curioso notar que en la especificación del lenguaje Java aclara que los arrays pueden contener un máximo de elementos basados en un indice de 32bits y es un error hacer: "long var=5; int mat[]=new int[5]; mat[var] =1;". Evidentemente ni los diseñadores de Java tuvieron en cuenta entornos de ejecución futuros y realmente tener un "long" que en realidad es un entero común en 64bits no es muy convincente, adicionalmente en memoria los tipos de datos de la JVM 64bits no ocupan necesariamente lo esperado, por ejemplo el long ocupa 128bits en el stack. Repito que no es un ataque a nadie, la idea es mostrar como no pensamos en ello, incluso personas con muchisima experiencia y conocimientos - como el profesor del ejemplo - no piensan en ello.

Básicamente, los profesores enseñan a los alumnos a construir casas con palitos y fósforos apilados. Pero no lo hacen por maldad, lo hacen por ignorancia, pero por sobre todo lo hacen por falta de profundidad y visión, es que se educaron durante años en un ambiente donde todo el mundo acepta que el software que construye es tan duradero como una escultura de hielo en epoca invernal o una de arena realizada en la playa durante la baja mar.

Todos, quienes estamos en esta profesión debemos de cambiar nuestra manera de pensar, debemos de ser altamente críticos, constructivos, y entender que en la ingeniería de software existe prácticamente todo por construir e inventar, no nos tiene que gustar que nos mientan como nos mienten, el software actual es precario, frágil, caro, ineficiente. Las técnicas y herramientas son primitivas, observemos el diseño de la mayoría de los compiladores nada más, prácticamente no han cambiado en treinta años. Debemos ponerle pasión a nuestra profesión, ingenio, creatividad, debemos encontrar las herramientas adecuadas para construir mejor software, más sofisticado, a menor costo, más durable por favor!!! no puede ser que un software dure menos de cinco años, de hecho no deberíamos de aceptar ningún software que no dure al menos cincuenta años. Si lo que acabo de decir le parece exagerado al lector eso muestra que querido lector no posee la profundidad de visión ni la convicción en su profesión ni la confianza en si mismo de ser capaz de lograrlo lo cual creo muestra que mi punto sobre la precariedad de la ingeniería de software es acertado.

La clave es ser activos en este problema y proponer soluciones al menos parciales. En una conferencia en Buenos Aires para el lanzamiento de .NET en Argentina en 2002 tuve la oportunidad de presenciar un auditorio lleno de profesionales aplaudiendo a la gente de microsoft con minúscula cuando les decían en la cara que todo el software desarrollado que tenían no servía más y lo tenían que reescribir en .NET o resignarse a que entre en estado de putrefacción mientras microsoft quita el soporte a sus plataformas anteriores. LOS APLAUDIAN!!!

Ya venia pensando en algo como LayerD hacia unos años pero esa experiencia fue una de las cosas que me hizo decidir a dedicarle tiempo y tratar de proponer yo mismo un conjunto de herramientas para empezar a encarar la estupidez en la ingeniería de software.

LayerD humildemente trata de considerar todos los principales problemas de la ingeniería de software a nivel global histórico y que tienen que ver con la baja durabilidad, calidad y el alto costo de desarrollo. Por tanto, LayerD provee medios para manipular de forma automatizada y programable cualquier componente de la implementación de un software - el código fuente - y mecanismos modulares para tener siempre una puerta abierta con la cual adaptar nuestra implementación a cualquier plataforma actual o futura. Sin lugar a dudas, LayerD distará de ser la herramienta y maquinaria perfecta, pero al menos proporciona medios para empezar a encarar este problema que no vemos y nos afecta a todos en múltiples niveles.

Por ejemplo, mediante classfactorys es posible encapsular APIs y diferencias entre entornos de ejecución diversos de forma transparente y sin incurrir en perdida de performance necesariamente. Las classfactorys interactivas permiten encapsular herramientas RAD de forma independiente a cualquier runtime, lenguaje de alto nivel o IDE de desarrollo. La posibilidad de utilizar lenguajes de dominio especifico y programación orientada al lenguaje abre la puerta al diseño de software más abstracto, reutilizable y mantenible. Las capacidades de análisis de código en tiempo de compilación permite integrar herramientas que en la actualidad se deben manejar de forma separada y realizar análisis exhaustivos de código y son además sencillas de programar. A partir del 29 de abril del 2008 - cuando esten disponibles para todo el mundo que le parezca interesante - empezare a mostrar con ejemplos como estas palabras abstractas se convierten en algo concreto usando el framework LayerD.

Con estos pequeños pensamientos espero despertar la curiosidad en los lectores e incitarlos a no conformarse con lo que nos venden y cuentan, ser críticos, buscar y desarrollar si es necesario mejores alternativas para elevar la calidad y durabilidad del software, para pasar en algún momento de la época de las cavernas a la modernidad. Espero sinceramente que la próxima década los ingenieros de software nos encontremos con un panorama mucho mejor en el cual dispongamos y sea común la utilización de nuevas herramientas como LayerD y otras similares que estan viendo la luz en estos días.

La proxima vez que vayamos a una conferencia de estos "evangelizadores" y nos diga "esto si funciona, es mejor que lo que antes te dije que era mejor, esto es estándar y lo soportaremos por largo tiempo" no le creamos y mostremos nuestro dedo del medio bien en alto, le hagamos saber que no somos niños, somos adultos así que no nos vengan con soluciones baratas con escaza ingeniería y creatividad - por no decir cero -, perdón por el tono, pero el software es mi vocación y como todos los que amamos esto queremos contribuir en algo mínimo y es irritante como muchas empresas nos tratan como niños ciegos que no podemos ver más halla de nuestra nariz. Tratemos de ver el problema con profundidad histórica y técnica, de lo contrario nunca lo solucionaremos, si seguimos creyendo que un estándar - corporativo o no - durará por siempre y esperamos las soluciones a los problemas de nuestra profesión vengan de estas mismas empresas estamos perdidos.