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.