El futuro digital. Cómo y por qué evitarlo.

La informática, la digitalización, se nos proponen como ayudas indispensables para facilitarnos la vida y para la solución de muchos problemas diarios. Y en la medida en que las cosas están así, hay que darle la bienvenida. Si la informática nos simplificara realmente las cosas en la medida en que los tecno-entusiastas nos dicen, quizás podría incluso valer la pérdida del contacto humano y la alienación que supone. La civilización digital nos hace más solos, más egoístas, más narcisistas y menos solidario. Pero, por lo menos, ¿nos ayuda a resolver los problemas diarios?

 Quiero empezar hablando de una experiencia personal. Hago una premisa: como resultará claro a continuación, todo empieza con un error mío. Si yo no me hubiera equivocado, la situación de que hablo no se habría creado. Por otro lado, considero que el sistema con que me relaciono (ya sea una persona o una máquina) debería ayudarme a descubrir y corregir mi error, y no debería empeorar las cosas.

 Hace una semanas tuve que renovar mi tarjeta sanitaria Europea. Me conecté a la página de la seguridad social, inserté todos los datos que me pedían y recibí el confortante mensaje que todo estaba bien y mi tarjeta me llegaría por correo. Sin embargo, pasadas pocas horas recibí un email que decía, literalmente, que según los datos de su base de datos no me podían expedir la tarjeta, y que llamara a un número que me proporcionaban.

 Ningún problema: llamo el número y tengo la mala sorpresa de que no consigo hablar con una persona, sino que me contesta una máquina. Supero mi reluctancia a contestar a voz a una máquina (es una cosa que me genera una repulsión instintiva: tolero teclear si me lo pide una máquina, pero hablar es algo que siempre he reservado para los humanos: no quiero hablar con máquinas) y repito todos mis datos. La voz mecánica me dice, despiadadamente, que según la base de datos no me pueden expedir la tarjeta y que vaya a la página web. Catch 22 perfecto.

 Tras intentarlo varias veces (por si se trataba de un problema técnico transitorio) recurro al sistema tradicional: un amigo de un amigo que trabaja en la seguridad social. Intercambiamos un par de email, le mando todos mis datos (por si acaso el problema con la base de datos es que no tienen mis datos correctos). El amigo actualiza los datos y me pide que lo intente otra vez. Mismo resultado. El amigo encarga a otra persona, que trabaja directamente en el departamento que se ocupa de estas práctica, que lo intente. Mismo resultado.

 El amigo me envía un email pidiendo disculpa por los líos de la burocracia, y yo le contesto que, en realidad, como profesor de informática, me a mucha rabia que la informática cause estos problema. Aquí se le enciende la bombilla: "Me dice que eres profesor... ¿no será que estás con muface?" Suenan las campanas y sale el sol: efectivamente estoy con muface, y es muface que se ocupa de esas cosas para sus afiliados.

 Me conecto a la página de muface y, hip hip horray, en unos días tengo mi tarjeta.

 Como he comentado, todo nace de un error mío: no he considerado que mi petición tenía que gestionarla muface. Por otro lado, el sistema informático no sólo no me ha ayudado, sino que ha empeorado las cosas con un mensaje sibilino que apuntaba a un problema en mis datos.

Otro ejemplo. Este años también he decidido vacunarme de covid y, por razone que ahora no vienen a tema, he necesitado coger una cita en el centro de vacunación en el Hospital Zendal. Me pongo en la página web, elijo el día (operación afortunadamente fácil: el centro está esencialmente vacío) y digo al sistema que sólo quiero imprimirme el resguardo, no lo quiero ni por móvil ni por email. Me llega en pantalla la página con el resguardo y falta la cosa más importante: el código de la cita, esencial para identificarla.

Ahora empieza el problema: no puedo acudir a la cita sin código. Por otro lado el sistema ya tiene almacenada una cita mía y no me permite sacar otra. No la puedo cancelar ni cambiar porque para hacer esto necesito el código. Catch 22. Me han metido en un bucle infinito.

Afortunadamente en este caso el elemento humano intervino: en el día y a la hora prevista me fui al hospital y, dado que no había nadie esperando, me dijeron que no había problema.

Son sólo un par de ejemplo, bastante banales, de los problemas que puede causar una digitalización exagerada y apresurada. No es difícil extenderlos, como contrafactual, a situaciones más serias y peligrosas.

 Hay varios problemas con la digitalización forzosa a que estamos sometidos, algunos técnicos, otros sociales o logísticos. Quiero aquí repasar algunos.

La primera observación puede parecer obvia: un sistema crítico debe funcionar. Siempre. Todas las características "cool", todos los colorines, todos los enlaces son inútiles si el sistema no hace lo que tiene que hacer. Lamentablemente en el ámbito de Internet esta observación ya no es nada obvia. El concepto de calidad del software, me parece, nunca ha penetrado el mundo de Internet, en que producir algo rápidamente es más importante que garantizar su funcionamiento. Los estándares de calidad para aplicaciones críticas deberían ser tan estrictos como los de los sistemas de control de un Airbus A380. Estamos muy lejos de esto. Hasta los lenguajes de programación usados (el tremendo Javascript es un ejemplo) parecen diseñados para reducir la calidad en lugar de aumentarla.

El problema se hace más grave en cuanto muchas aplicaciones se desarrollan directamente como aplicaciones web, que suponen un contacto continuo con el servidor, en lugar de desarrollarlas como aplicaciones locales que sólo contactan con el servidor para mantener al día los datos (solución más compleja y cara, pero mucho más segura). Esto hace que cada vez que, por alguna razón, Internet no funcione, al trabajo se pare completamente. En algunos casos (esto ha pasado ya varias veces en centro de salud de Madrid con el acceso a las historias clínicas y a la receta electrónicas), las consecuencias pueden ser muy serias.

Hemos empezado a depender de manera crucial de programas informático justamente en el momento en que su calidad se ha reducido dramáticamente, en el momento en que la calidad del producto dejaba de ser el foco principal de la metodologías de desarrollo. Esta falta de calidad las vamos a pagar muy caras en el futuro.

Se trata de un fenómeno que podemos notar en varios ámbitos. En la red ferroviaria de Cercanías de Madrid hay, entre otros, dos modelos de trenes: los 446, de los años 80, y los varios Civia, que entraron en servicio en el año 2000. Los 446 tienen, por encima de las puertas, unos indicadores relativamente sencillos: un indicador a Led en que aparece, deslizándose, la hora, la temperatura y la próxima estación. Los trenes Civia tienen varias pantallas, que pueden, en principio, mostrar mucha más información. El problema es que, mientras nunca he visto un tren 446 con un indicador a Led que no funcionara, estimo (en la base de mi experiencia) que las pantallas de los Civia funcionan y dan la información correcta un 20% de las veces. El resto de las veces están apagadas, dan una indicación equivocada, o muestran la pantalla inicial de Windows XP (Si: Windows XP. Sí: en 2024).

Esto pone en evidencia un segundo problema muy común en la digitalización: basar aplicaciones, incluso algunas críticas, en sistemas operativos inestables y poco fiables tales como Windows. El uso de Windows XP en el momento de la creación de estas aplicaciones ha creado una situación en que o uno se queda dependientes de un sistema operativo viejo y que Microsoft ya no soporta, o invierte una cantidad importante de tiempo y dinero en rediseñar completamente el sistema cada vez que una nueva versión es incompatible con las anteriores. Más razonable habría sido usar un sistema como el núcleo de Linux que es, esencialmente, el núcleo de Unix, y es compatible con versiones de hasta hace 50 años. Pero desarrollar en Linux supone un esfuerzo inicial más grande, y en el software hoy en día se mira más al ahorro y la rapidez de desarrollo inicial que a la calidad en el largo plazo. Otro fenómeno que, si asociado a aplicaciones críticas, tendrá consecuencias desastrosas.

Un tercer problema es el contexto semántico. Un programa que implementa una función dada debería hablar en el lenguaje del problema que resuelve, y crear funciones típicas del problema que resuelve. Un programa para reproducir música debería exponer funciones y conceptos relacionados con la música y nada más. Un programa de contabilidad debería hablar de contabilidad y nada más. Un programa debería permitir a quien lo usa hablar su lenguaje y usar los conceptos y las funciones típicas de su campo, no del campo del programador.

El programa para la obtención de la tarjeta sanitaria viola este principio en el momento en que me comunica que "la base de datos" no le permite satisfacer mi petición. Yo, usuario del servicio de salud, no tengo porque darme cuenta que existe una cosa llamada "base de datos". Lo que sé es que existe una tarjeta sanitaria y que quiero conseguirla. Nada más. El mensaje de error debe ser útil a mi, no a quien escribe el programa. Ninguna interacción debería depender del hecho que se está usando un programa.

 

Finalmente, la digitalización debería resultar en procedimientos sencillos e intuitivo y siempre debería existir la posibilidad de recurrir a un operador humano. Incluso algo tan sencillo como pedir una cita en un centro de salud se ha transformado en algo muy complicado para personas mayores sin acceso a instrumentos informático. Aquí en Madrid (no conozco la situación en otras comunidades) se ha creado una app para móvil que gestiona, entre otras cosas, la petición de citas. La app es útil para mucha gente, pero se está contando tanto con ella que los métodos alternativos se han complicado y han perdido eficiencia. Llamar por teléfono, por ejemplo, no nos lleva a hablar con un operador, sino a un menu automatizado. Esto es algo inaceptable: la digitalización debería aumentar el número de posibilidades para hacer las cosas, no complicarnos los instrumentos que ya teníamos.

 

Lamentablemente muchas veces los programadores no siguen la primera norma que se recomienda en todos los manuales de metodologías de programación: hablar con el usuario final de una aplicación. El resultado son programas que no cumplen las funciones que sus usuarios necesitan, que obligan a recurrir a "apaños" y que a menudo hacen perder más tiempo de lo que hacen ganar.

Al mismo tiempo, la promesa de ahorro que estos instrumento prometen (a costa de puestos de trabajo y, por ende, del bienestar de las personas, pero, hoy en día, ¿a que administrador le interesa esto?) hacen que utilicemos cada vez más, para operaciones cada vez más críticas, instrumentos imperfectos, obscuros, complicados de usar, eliminando al mismo tiempo cada otra vía para hacer lo que necesitamos.

 

Una receta para el desastre. Pero quizás nos consolará la constatación de que será un desastre digital, conectado, y de última generación.