Deja Vu

No es la primera vez que tengo esta sensación de haber vivido una y otra vez la misma situación con el desarrollo de software.

Observen la siguiente pantalla:

La imagen superior muestra uno de los tantos procesadores de texto en línea que han surgido últimamente.

Ahora vean la siguiente imagen:

Muestra una "ventana" para la configuración de la página en dicho procesador de texto en línea.

Tenemos dos formas de analizar esta pieza de software, por cierto muchos pensarían que es una excelente obra de ingeniería de software. En la imagen no se puede apreciar, pero el procesador de texto en realidad posee un completo sistema de manejo de ventanas incluyendo arrastre, redimensión en algunos casos, lógica de foco de controles, una multitud de controles de usuario "AJAX" como tabs, combos, barras de herramientas, paneles ocultables, etc.

Si analizamos todo el trabajo que lleva desarrollar una aplicación de este tipo no nos queda más que pensar que estamos en presencia de una buena pieza de software.

Por otro lado, al entrar a dicho procesador de texto en línea, tuve múltiples deja vu simultáneos. Me recordaron cuando implemente un patético sistema de "ventanas" (no móviles por cierto) en QuickBasic usando caracteres en la consola de DOS de 80x25 caracteres ASCII J. Me recordó cuando implemente otro rudimentario sistema de ventana para otra aplicación DOS esta vez en modo grafico usando VGA de 320x200 pixeles a 256! colores simultáneos para un programa de diseño vectorial también en QuickBasic y como cambiaba la paleta de colores usando la INT 10 si mal no recuerdo o capturar las coordenadas del mouse usando los registros AX BX CX y DX por medio la un tanto odiada por mi interrupción 33 (solía no cargar el controlador del mouse en autoexec.bat). También me acorde de otro mini sistema de ventanas hecho ya en una mezcla de C++ y C (nunca olvidare cuando descubrí los punteros a función J que bendición!!!) en el modo VGA de 640x480 y 16 colores, esta vez con ventanas móviles y redimensionables, captura de algunos eventos y unas primitivas para dibujar cubos en 3D en perspectivas ortogonal y logarítmica (perdón por tantos recuerdos :-P). Y al acordarme de todo eso pensé "cuando construí esos primitivos sistemas de ventanas era un adolescente que jugaba programando, sabía nada de ingeniería de software (y no porque piense que ahora se mucho)".

Al ver otro procesador de texto "re-implementado" para la web se me vinieron a la mente multitud de procesadores de texto, sistemas de ventanas, IDEs, planillas de cálculo, juegos, todos re-escritos infinidad de veces hasta el cansancio en diferentes sistemas operativos, entornos de ejecución y plataformas de hardware.

La verdad es que aplicaciones como éste procesador de texto le pueden parecer muy lindas y desarrolladas aplicaciones a los desarrolladores más jóvenes, pero a mí, sólo me recuerdan el estado del arte en la ingeniería de software. Me recuerdan que no somos capaces de reutilizar seriamente ningún desarrollo importante más allá del tiempo de vida de la plataforma de desarrollo original de la aplicación. Me recuerda lo primitivos que somos y cuanto tenemos para crecer en software. Lo cierto es que este tipo de aplicaciones cuando surgen una y otra vez (últimamente los celulares y la web se llevan todos los premios a la reescritura de viejas aplicaciones en nuevos runtimes) no hacen más que mostrarnos que mucho no hemos avanzado como ingenierosJ, o al menos eso me parece.

Si el software es algo abstracto, y un procesador de texto es un procesador de texto se ejecute en DOS, Windows, Linux o en un servidor Web o en un explorador, porque debemos de reescribirlo una y otra vez cada vez que surge un nuevo entorno de ejecución o una nueva serie de librerías de base??

La verdad es que ello no es necesario, simplemente aparentemente a poca gente le preocupa el tema (sobre todo a las grandes empresas proveedoras de software de base parece no importarles jeje), a mi me parece inaceptable si queremos llamarnos verdaderos ingenieros alguna vez en la vida.

En los próximos post "productivos" espero poder empezar a mostrar como con LayerD es posible encarar esta limitación en la ingeniería de software actual y resolver el problema del acoplamiento del software con un API en particular o un entorno de tiempo de ejecución. Con suerte, podré demostrar que el acoplamiento entre software implementado+API+runtime no es necesario y es posible desarrollar software abstracto que siempre posea medios automatizados para ser adaptado a nuevos entornos de tiempo de ejecución o APIs que surjan en el futuro. Así quizás en un futuro no vuelva a tener todos estos deja vu y deje de considerar a nuestra profesión precaria.