Hace algunos años, trabajé en una compañía que desarrollaba una aplicación de gestión de ventas para concesionarios de automóviles. Esta empresa era reticente a saltar al carro de la nueva tecnología. De hecho, decir que esta compañía evolucionaba lentamente no es una exageración, es una afrenta a la misma palabra “retraso”. 1200 baudios: es lento. El correo en vacaciones: realmente lento. El movimiento del glaciar: realmente, realmente lento. Esta compañía: algo así como la fosilización. La compañía desarrolló la primera versión de su producto en 1973 usando COBOL y IBM System/3.
Fue un éxito inmediato: centenares de representantes compraron su producto y diez millones de dólares en ventas entraron en la compañía. Habían descubierto la fórmula correcta y no deseaban cambiarla.
A pesar de los numerosos adelantos tecnológicos de la década siguiente, permanecían en sus trece y continuaron mejorando y optimizando su producto para la plataforma System/3. Incluso se llegó al punto donde comprar un System/3 anticuado resultaba considerablemente más costoso que comprar una computadora a estrenar mucho más potente. Pero eso no importó; su sistema funcionaba y no había necesidad de cambiarlo.
Y entonces sucedió: IBM anunció que el sistema System/3 dejaría de mantenerse. Enfadados, pidieron a IBM que continuara apoyándolo.
Al ser ellos uno de los clientes usuales del System/3, IBM se ofreció enviar un equipo de consultores para ayudarlos en la transición a la nueva plataforma x86. La compañía lo rechazó.
En su lugar, emplearon un pequeño grupo de frikis para desarrollar un emulador que permitiría ejecutar las aplicaciones de System/3 en el x86. Extrañamente funcionó y no hubo necesidad de cambiar nada más.
El emulador trabajó bastante bien durante varios años y continuaron desarrollando su producto en COBOL para System/3 y ejecutándolo en un x86. Hasta que el fabricante de su compilador de COBOL dejó el negocio.
La mayoría habría intuido que era el momento de cambiar a un nuevo lenguaje y a una nueva plataforma de hardware. Ellos no.
Su solución fue, otra vez, emplear un equipo pequeño de frikis para desarrollar su propio compilador de COBOL que traduciría todo el código COBOL a C para posteriormente compilarlo como una aplicación para el x86. Extrañamente funcionó y no hubo necesidad de cambiar nada más.
Por supuesto, uno de los problemas más grandes de su traductor/compilador de lenguajes era que producía un código C totalmente ilegible que ninguno de los programadores de COBOL llegaba a entender y aún menos a poder utilizarlo para eliminar errores de la aplicación.
Los frikis fueron invocados de nuevo para crear un entorno de desarrollo de COBOL más amigable que pudiera depurar el código paso a paso. Asombrosamente, funcionó y pudieron continuar desarrollando en System/3 COBOL durante la siguiente década.
Estábamos ya en 2001 y la compañía volvía a necesitar otro equipo de frikis. Y aquí es donde yo entré en juego. La compañía deseaba extender su alcance en Europa, pero el mercado europeo estaba plagado de esa nueva tecnología de lujo llamada “Windows.” Dado que daba problemas funcionando bajo la consola de Windows, nos llamaron a unos cuantos para ayudarlos a abrazar la “nueva” tecnología de Windows. Obviamente, se les aconsejó desarrollar plenamente en C/C++ y en un entorno real de desarrollo bajo Windows, pero cayó en oídos sordos. Nos pusimos manos a la obra para intentar buscar una manera de traer su System/3-COBOL-traducido-a-C al mundo de Windows.
Uno de los retos era el control de eventos de COBOL, o más exactamente, su carencia. En Windows, cuando un usuario pulsa un botón se dispara un evento para indicar lo que ha ocurrido. En COBOL, el programa pregunta periódicamente si el usuario realizo una acción.
Se intentó trabajar alrededor de esta idea creando una “cola de acciones” que permitía que COBOL viera qué estaba sucediendo y poder responder al suceso.
El desafío siguiente consistía en crear un interfaz para la aplicación, o, más exactamente, crear un generador de interfaces que traduciría las pantallas de la consola a las formas de ventanas de Windows. Se consiguió increíblemente hacer eso, también.
Asombrosamente, una vez que “el proyecto de la conversión a Windows” se realizó exitosamente, su software trabajó correctamente en esta plataforma.
Su aspecto era terrible, funcionaba increíblemente lento y requería muchísima potencia de procesador y muchísima memoria RAM, pero funcionaba. La compañía podía seguir manteniendo su piso entero de programadores de COBOL que trabajaban desarrollando en System/3-COBOL-traducido- -a-C-renderizado-en-Windows.
Después de todo, encontraron una fórmula que funcionó y no había porque cambiarla.
Adaptación de thedailywtf.com
Comments