Ayer a primera hora de la mañana el tráfico aéreo con destino u origen en el Reino Unido se vió afectado por un problema con los ordenadores que gestionan los centros de control aéreo que obligó a reiniciar el sistema, con el consiguiente parón; hace una semana pasó algo similar en el aeropuerto de Dublín y a principios de mayo sucedió algo parecido que obligó a detener el tráfico aéreo con destino al sur de Tejas y partes de Louisiana y Nuevo Méjico.
Hoy se ha sabido que el Royal Bank of Canada lleva un retraso de varios días en cuanto a la actualización de los datos de sus clientes y que muchos todavía no han cobrado sus nóminas -aunque haya sido dada la orden de pago por parte de su empresa- ni saben realmente cuanto dinero tienen en sus cuentas.
¿La causa de estos problemas? Software que no se comporta como se esperaba.
Ojo, que aquí en España tampoco nos libramos, ni mucho menos, como por ejemplo sucedió con el sistema informático de 30 millones de euros que se supone iba a agilizar los trámites de justicia en Madrid, que se cayó en cuanto se intentaron poner en marcha los juicios rápidos, o como cuando se cayó la red de telefonía móvil de Airtel (ahora Vodafone).
Todos estos casos, afortunadamente no parecen haber causado daños personales, pero es fácil encontrar casos en los que fallos en el software han producido muertes, como por ejemplo cuando una batería de misiles Patriot no identificó un blanco y no disparó contra él durante la primera guerra del Golfo, o como el de los controles del Therac-25, un aparato de radioterapia, que funcionaban mal e indicaban que se estaba aplicando una dosis de radiación mucho menor de la real.
Otro caso soprendente es el del accidente del vuelo 603 de Aeroperú del 2 de octubre de 1996, producido porque el sistema informático del avión (un Boeing 757) se volvió loco a causa de la obstrucción de uno de los juegos de puertos estáticos que miden la presión atmosférica para calcular la altura y velocidad del avión: en lugar de indicar que había una discrepancia entre los datos que proporcionaban los puertos estáticos de la intrumentación del capitán y los del copiloto, el sistema a ratos no daba datos y a ratos daba datos incorrectos, llegando -entre otras- a dar a la vez alarmas de exceso de velocidad y de peligro de entrada en pérdida por ir demasiado despacio, lo que evidentemente no puede suceder a la vez. Dado que el vuelo era de noche y al no poder confiar en sus instrumentos, los pilotos estaban a todos los efectos volando a ciegas -no me explico, salvo por un exceso de confianza de dudosa justificación a la vista de los hechos, como no hay unos instrumentos mecánicos básicos de backup en la cabina- por lo que terminaron por chocar con el mar cuando intentaban volver al aeropuerto y creían estar volando a una altura segura.
No es difícil encontrar más ejemplos de los problemas que puede crear el software mal concebido bastante más graves que el cuelgue del ordenador en el que llevas un rato trabajando sin guardar, como la explosión del primer Ariane 5 o la caída de las líneas de larga distancia de AT&T en enero de 1990, pero lo preocupante es que no da la impresión de que las cosas hayan mejorado mucho desde que yo estudiaba Ingeniería del Software hará quince años y me hablaron por primera vez de la crisis del software.
Una vez más, no puedo dejar de pensar en Normal Accidents, el libro en el que Charles Perrow argumenta que es normal que ocurran accidentes dada la complejidad de los sistemas que usamos y el poco control que tenemos sobre ellos en cuanto se salen de los parámetros normales de operación, aunque es un riesgo que todos parecemos dispuestos a aceptar.
¿Es realmente el software el que está fuera de control o lo somos nosotros?
