Los amantes del código bien temperado

Hace poco, buscando otros asuntos, me dí con una discusión acerca del uso de "Obsydian", en la que alguien quería conocer experiencias de su uso, y alguien (no me interesa mencionar otros datos, porque no es el caso la persona) envió la siguiente contestación:

Personalmente no he trabajado con obsydian. Fui contratado para desarrollar y mejorar unas aplicaciones. Estas estaban desarrolladas con Obsydian. Realmente las hice de nuevo ya que la cantidad de códigos que mete la herramienta, es imposible hacer mantenimiento si no utilizas la herramienta. Como cualquier herramienta para programar (la que utilice genera código rpg) debe tener la mayor cantidad de posibilidades o rutinas para que estas sean efectivas, lastimosamente al desarrollar o crear el programa introduce todas estas rutinas aunque no se utilicen en programa desarrollado. Los programadores de otra instalación que desarrollan con obsydian me dijeron que era fácil de utilizar y rápido para crear programas. Me di cuenta que no eran programadores con experiencia en RPG y los rete a que ellos utilizando obsydian y yo programando en la manera tradicional quien terminaban primero, no aceptaron el reto. En una tercera instalación fui contratado (soy programador independiente) para desarrollar unos programas para mantenimiento de unas bases de datos, las cuales habían sido desarrollados con Obsydian, la verdad no se por que no utilizaron la herramienta para los programas de mantenimento. En el desarrollo de los programas se necesito cambiar las bases de datos. Yo propuse cambiar las bases de la manera tradicional, directamente en las DDS en el PDM, por alguna razón el analista no quiso y utilizo la herramienta para el cambio de las bases de datos, la verdad es que fue muy bonito la cantidad de pantalla y pantallitas de windows que se abrieron para cambiar y introducir un campo nuevo en la base de datos, y creo que mi hijo que no sabe programar para el As400 con esta herramienta la habría hecho, yo le dije que yo habría hecho el cambio en menos tiempo, mucho menos, pero bueno el era que el mandaba.
Conclusión si eres buen programador y tratas de crear un estándar en la programación, lo documentas bien, puedes reciclar estos códigos una y otra vez no necesitas una herramienta. Las personas que han corregido en alguna ocasión mis programas me han dicho lo fácil que resulta dar mantenimientos a estos, ya que cuando has visto uno se puede decir que ya los vistes todos. Las herramientas son buenas si quieres contratar gente sin experiencia y que vienen del mundo de ventanas.

Encuentro en esta contestación dos motivos fundamentales. Uno, la inconsistencia en la adopción de una herramienta por parte de la empresa usuaria. Otro, el punto de vista del programador. Sin embargo, quizá ambos confluyan a una idea compartida: Una herramienta "generadora de código" no es confiable, y un programador lo puede hacer mejor. En definitiva, ¿cómo es posible que una empresa que usa una herramienta de cuarta generación, la reemplace por un trabajo manual, o por decirlo de la misma forma, de tercera generación? Aunque sin duda se pueden alegar defectos del producto, creo que es la escasa adhesion al concepto, lo que produce la actitud del propietario de la herramienta.
Este es un punto de vista recurrente con el que tropecé en muchas ocasiones, que trabó antes y ahora muchos intentos de racionalizar la construcción de software, y no sólo en este terreno, sino también en otros: herramientas para la administración de cambios y uso del diseño visual (uso de diagramas). En resumen, la idea básica es que en la construcción de software lo más importante es el trabajo personal, y que programar es un arte que no debe ser cedido a procedimientos automatizados.
En el pasado, he trabajado con colegas que desconfiaban del producto generado, y revisaban el código resultante, y lógicamente, lo criticaban tal como lo hace quien escribe arriba. Lo que aquí se pierde es el bosque, por destacar al árbol.
Lo que el programador que escribe no observa, es la diferencia en productividad y consistencia:
No advierte que no se trata de comparar un programa, sino el conjunto entero de aplicaciones que compondrían el patrimonio de la empresa en que estaba: Su proposición implica que cada programador escribirá su programa, siguiendo estándares tan durables como lo fue la adhesion a la herramienta 4GL de la que habla: un año después de que el programador freelance desarrollara sus programas con el estándar A, llegará el freelance siguiente, que impondrá el estándar B, y criticará al 4GL, y al A. Como bien se vió durante la crisis del año 2000, al cabo de 5 años de desarrollos, un gran número de programas ya no son reconocibles, llegando al extremo de que algunos objetos se ejecutan sin código fuente.
Como bien dice, "es imposible hacer mantenimiento si no utilizas la herramienta". De eso se trata justamente.
El programador desafía al equipo que usa el 4GL a una competencia. Seguramente les ganará en un programa y un DDS (definición de una estructura de datos RPG), porque en el 4GL, Obsydian en este caso, se definirán elementos "superfluos", y ello mediante el uso del IDE del producto. (Ah, qué tiempos aquellos en que escribíamos en la línea de comandos de la consola!). Lo que debiera el equipo desafiado, es proponerle competir en un proceso completo, durante un año. Allí veríamos la diferencia que existe entre un programador que modifica directamente un DDS, y otro que construye un repositorio integrado. La diferencia la veremos cuando haya que producir una modificación que impacte sobre 50 programas y 30 DDSs, o cuando deba agregar un nuevo proceso, y cambiar cinco tipos de datos.
El programador se burla del analista que se niega a cambiar directamente el DDS, y de las "pantallitas" que se usaron para cambiar un tipo de datos, como lo hace del equipo que utiliza un 4GL. Lo lamentable es que proliferen (y no sólo en el RPG, sino en cualquier ambiente), los desarrolladores que piensan de esta forma, y desacreditan a quienes se esfuerzan por construír con "esas tonterías" donde no se puede hacer un algoritmo elegante.
Pero aún más lamentable, es que una empresa que adquiere un producto de esta clase, no mantenga el estándar, y deje a medio camino la inversión volviendo atrás, al recurrir a programadores que interfieren el código desde fuera, como lo indica el caso comentado. O cuyos usuarios no están convencidos del valor de lo que están haciendo.
Existe un promedio de desarrolladores convencidos de que lo fundamental es escribir código, y ven a los 4GL con hostilidad, y su peso, sumado a las partes no interesadas en el predominio de herramientas CASE, hacen que el uso de estas herramientas sea mucho menor que lo que se pudiera recomendar.

Food for Thought

Gracias a Quasimodo, usuario de un sitio argentino dedicado al C++ conocí la página "Food for Thought" de la Universidad de Sussex, en el Reino Unido. Si a alguien le interesa estudiar materiales básicos de programación en C++ y Java, Arquitecturas de Procesadores, Sistemas Operativos, Redes, Seguridad, Criptografía, Matemáticas, y otras disciplinas de base más, debe hacer una visita a la página. Y, con un poco de curiosidad, puede seguir visitando, por ejemplo, los nombres y antecedentes de sus profesores, los proyectos en desarrollo, las actividades de la Universidad, y, por qué no, el estilo de presentación de sus materiales, y su disponibilidad.
Luego, puede detenerse unos minutos, y pensar cuánta es la distancia entre esta Universidad, y lo que en nuestros países disponemos o planeamos.

Ajustando la nota anterior...

Un día después de escribir la nota anterior (Plex y MDA), Lucio Gayosso me alcanzó la presentación hecha el 1 de noviembre en Praga por Bill Hunt, que contesta mi nota con creces, estableciendo al soporte de los estándares MDA y UML como Candidate Release del producto. El horizonte de desarrollo para los próximos tres años establece una línea de profundización en el soporte de Java, particularmente J2EE y EJB, el soporte de .Net, y el soporte de servicios Web. Como era de esperar, la inclusión de Plex en el grupo Allfusion lo coloca en la corriente principal de herramientas de desarrollo de Computer Associates, creando la posibilidad de planear su uso como parte del manejo del ciclo de vida completo de un producto software. La perspectiva es la de integrar mejor (ya es posible) Plex con ERwin como modelador visual, con Harvest como administrador de código fuente producto, con Unicenter WSDM como administrador de servicios web, como aspectos explícitamente mencionados.
Y en particular, la inclusión del soporte de UML y MDA como Release Candidato, implica darle un poder y flexibilidad único a Plex, ya que se potenciará su capacidad integradora, tanto dialogando con otras herramientas (al poder intercambiar modelos con XML), como en su virtud de abordar arquitecturas complejas de aplicaciones de empresa.
Justamente, un elemento importante de la presentación de Bill, es destacar lo que ya hoy es un hecho, que a mí también me ha llamado la atención, que es la cantidad de recursos que hoy mismo dispone Plex como herramienta de integración utilizable en soluciones EAI, lo que indudablemente se extendería aplicando un esquema MDA más explícito.
Tan pronto disponga una URL donde localizar el documento, la incluiré aquí.

UML y otras vías de construír software basadas en un modelo

Uno de los argumentos de los opositores a la generación de código a partir de un modelo del problema, es que no es posible representar mediante diagramas visuales todos sus aspectos, como lo dicen Scott Ambler o Martin Fowler. En el estado actual, y en base a la variedad de artefactos disponibles con UML, es posible que ese argumento sea bastante débil, ya que cualquiera de ellos pudiera mapearse a código ejecutable, más tarde o más temprano, con la ventaja adicicional de que remodelar produciría un efecto inmediato de doble vía entre la representación visual y el código.
Sin embargo, puede irse aún más allá. Basándome en Allfusion Plex (o Plex a secas, considerando su historia de cambios de nombre), se puede decir que no sólo es posible tener un diseño conceptual, abstracto, basado en UML, sino que el modelo puede ser representado por otros medios. Plex basa su descripción del problema en "triples", verbos que describen atributos de objetos, que forman un repositorio único que explica el modelo en todas sus partes, y en este repositorio, el modelo gráfico es una parte.
Plex y MDA crecieron conociéndose, y con cierto grado de intercambio. En el pasado, Synon primero, y Sterling después, participaron en la OMG de los esfuerzos destinados a la construcción de conceptos más sólidos en la elaboración de Software. Quizá hubiera que hacer en algún momento una breve historia de esta evolución. Pero baste recordar que Synon fue participante del proyecto San Francisco (dónde quedó?), y que Synon y Sterling fueron parte de los esfuerzos por elaborar estándares en el manejo de un repositorio, el UML, CORBA y los componentes en general, y aún se encontraron en alguna ocasión con Fowler en esfuerzos comunes en la definición de tecnología para construír patrones de diseño. Debiera revisar materiales de congresos de la década del 90 (especialmente el de 1999) para encontrar estas coincidencias pasadas.
Si lo viéramos desde el enfoque de Plex, el modelo es expresado en forma visual, pero no es dependiente de los diagramas de ningún tipo, sino de una descripción casi narrativa, conservada en un repositorio que puede ser exportada como XML. Podríamos decir que las visiones PIM (Platform Independent Model) y PSM (Platform Specific Model) son representados en Plex a través del modelo en su versión Base, y sus variantes. Las transformaciones entre una visión y otra no requieren otra actividad que la configuración del modelo en una variante, y esto es una acción simple, a condición de haber construído el modelo con una política de configuración premeditada. Se podría decir aún más, ya que la arquitectura que construye al modelo basado en una visión de cuatro dimensiones (Versión, Variante, Nivel, y Lenguaje), permite solucionar en el interior del modelo algunos problemas que todavía no ví bien expresados en MDA: el manejo de la versión como un complejo evolutivo histórico. Qué significa esto: que en el momento en que Plex finalmente integre una herramienta de diagramación, un diagrama determinado (de clases, de actividad), se crearía en una dimensión dada de la configuración (aunque fuera en la base), y aún podría explotar las ventajas de la configuración en una variante o una versión.
En lo que a mí respecta, quisiera tener la libertad de usar un diagramador para representar lo que hiciera falta. Sin embargo, los diagramas UML pueden usarse solo limitadamente hasta ahora importándolos a la IDE de Plex, y básicamente para ERD. En algún momento, con Sterling, existió planificado integrar varias herramientas de tal forma que hubieramos sido "MDA compliant". Sterling planeaba vincular Spex, Biz, Plex, Joe, como un solo conjunto capaz de iniciar un modelo desde el proceso de negocios, hasta el código ejecutable (Biz => Spex => Joe => Plex). El paso a Computer Associates implicó la reubicación de herramientas, y sólo ahora, uno o dos años después, es posible ver una vinculación entre Erwin => Joe => Plex.
Sin embargo, es UML la única vía de pasar de un modelo conceptual a código ejecutable?. Plex a vivido perfectamente usando un repositorio basado en otra forma de describir el modelo, sin perder la opción de usar UML u otro lenguaje de representacion visual como parte del conjunto de recursos, y agregando a partir de la versión 5.1 la posibilidad de exportar o importar un modelo a XML. Es razonable propugnar un estándar común, y UML tiene un camino recorrido como tal, pero quizá sea XML el verdadero medio de intercambio.
Es necesario agregar que UML encuentra resistencias también desde un punto de vista comercial, especialmente desde el momento en que Rational devino en una dependencia de IBM, y creo que Microsoft es uno de ellos.
En fin, esta nota requiere volver sobre ella una y otra vez, en la medida en que algunas tendencias de definan algo más. Digamos que la idea yacente en MDA es fundamentalmente aceptable, y que puede ser alcanzada por más de un camino, entre ellos, el que Plex adopta.