No sé qué sucederá cuando la IA empiecen a tomar las riendas de la programación y la gestión de sistemas. Tal vez siga todo igual. Ahora que esas tareas son mayoritariamente humanas parece que los informáticos somos expertos en buscarnos trabajo unos a otros.
El tener tantas opciones para hacer las cosas junto con la necesidad de mantener sistemas con edades y prestaciones diferentes genera mucho trabajo extra a la hora de introducir modificaciones en los sistemas informáticos. No es algo bueno ni malo es una situación que se produce en otras áreas. Pero en el mundo digital se nota más por lo rápido que se suceden aquí los cambios.
Estos días pasados hemos “sufrido” algunas de estas situaciones en las que uno trabaja casi más para adaptarse al ecosistema digital donde va a introducir una pequeña novedad que en lo que cuesta hacer lo que el cliente nos pide. Vamos con un par de ejemplos:
Hace un par de meses nos llama un cliente. Le hicimos una aplicación de gestión a medida para cubrir unas necesidades muy concretas de su empresa. Hace un año nos dijo que iba a dejar de usarla ya que sus proveedores habían desarrollado una aplicación web que le encajaba. Pero al final la aplicación web no funcionaba como ellos pensaban y el programa que tenían a medida les iba mejor. Este cliente recibía antes sus encargos por teléfono y grababan en nuestro programa las tareas pendientes. Ahora sus proveedores le daban esa información por web. Lo que estaban haciendo era copiar y pegar los campos desde la aplicación web a nuestro programa. Como la aplicación web soportaba API querían automatizar el proceso.
La parte del API en sí no fue muy complicada. Como nuestro programa tenía ya unos cuantos años encima lo que hicimos fue programa un modulo separado en C# para comunicarnos con el API. Configuramos un sistema de llamadas y respuestas de nuestro programa al módulo en C# para rellenar los campos de forma automática desde el API. Las primeras pruebas funcionaban bien… hasta que nos tropezamos con el primer trabajo no previsto: en los PCs del cliente no aparecían ni las letras ñ ni los acentos…
Tuvimos que empezar a mirar la configuración regional de los equipos del cliente. Como eran sesiones de Terminal Server contra un servidor que no habíamos montado nosotros no quisimos tocar el servidor. Una vez vista la versión del sistema operativo del servidor y la configuración de idiomas pudimos cambiarlo en los módulos que llamaban a la API para convertirlos antes de grabar. Tema resuelto.
Este cliente trabaja las 24 horas del día. Así que para poner en real los cambios en la aplicación deberíamos hacerlo de noche para molestar lo menos posible. Antes de instalar en el servidor en real, instalamos el programa en uno de los PCs del cliente y todo funcionó bien. Pero claro el día de la instalación en el servidor a medianoche no podía ir todo bien a la primera. Apagamos todo, copiamos las versiones nuevas y reiniciamos. Configuramos las rutas de acceso a las DLLs de los módulos de C#, las rutas a los ficheros de datos y arrancamos. Todo va bien, excepto que no se graban los campos. Nos ponemos a debugear y vemos que nuestro programa no es capaz de comunicarse bien con los módulos de C#: empieza la comunicación, pero no la termina. Al final tenemos que dejarlo y nos vamos a dormir y a pensarlo bien.
En la tienda ya por la mañana montamos una máquina virtual lo más parecida al servidor del cliente. Copiamos la estructura de directorios y los datos de pruebas. Y debugeamos otra vez, pero yendo más despacio y con más tranquilidad. El problema al final era que la ruta en la que estaban los ficheros de datos y los módulos de C# tenían espacios en blanco y guiones bajos “_”. En la llamada desde nuestro programa al módulo de C# en su momento habíamos tenido problemas con los espacios en blanco y teníamos una rutina que lo resolvía. Pero esta rutina no iba bien con los guiones bajos. El guión bajo lo había añadido la empresa que había configurado un cuadro de mando integral hacía un par de meses. Al final pudimos cambiar la forma hacer la llamada a los módulos de C# y la manera de comunicarse desde allí con nuestros ficheros de datos para poder usar en la ruta de llamada espacios en blanco y guiones bajos.
Calculo que dedicamos a estos dos temas un 10% del tiempo del proyecto. No hay nada como que otros informáticos nos ayuden a facturar más.
El otro asunto no es tan largo. Un cliente al que le montamos un solución de comercio electrónico nos llama. No se le actualiza bien ni el stock ni los precios. A este cliente además de montarle una tienda web le preparamos unas macros de carga de los ficheros de sus proveedores. Un par de proveedores habían cambiado los tipos de campos de los ficheros que enviaban… y al llegar a la web no entraban bien. Así que tuvimos que buscar las diferencias y añadir algunas rutinas de conversión extras. Esta situación si que se nos repite mucho. Pero es lo que tiene el progreso. Algo que lleva funcionando bien años deja de hacerlo porque otro miembro de la cadena lo cambia.
En resumen, que en los proyectos un poco complejos pasamos mucho tiempo adaptándonos a las configuraciones de nuestros clientes más que resolviendo directamente el problema. Pero es lo que tiene el disponer de más sistemas interconectados con otros muchos sistemas. Y es una tendencia que cada día irá a más… hasta que a lo mejor la IA lo resuelven.
