Este artículo se publicó originalmente en Cooking Ideas, un blog de Vodafone donde colaboramos semanalmente.
En unas cuantas ocasiones nuestra confianza en la tecnología y en que la dominamos perfectamente ha estado a punto de tener graves consecuencias, tan graves como que podían haber acarreado la extinción de nuestra especie y de buena parte de la vida sobre nuestro planeta.
Se trata de las ocasiones en las que estuvimos a punto de que se desencadenara una guerra nuclear de consecuencias imprevisibles a causa de fallos en la instalación de ciertos equipos o a causa de errores de funcionamiento de otros, en especial a causa de errores en el software que los controla.
Aunque si hoy estás leyendo esta anotación es porque afortunadamente la cosa nunca fue a mayores porque alguien, en algún sitio, se dio cuenta del error a tiempo.
Pero a lo largo de nuestra historia con los ordenadores y la tecnología ha habido otros casos en los que el fin de la historia no ha sido precisamente feliz.
Un caso arquetípico, y que hoy en día se estudia en facultades de ingeniería e informática de todo el mundo, es el del Therac-25, una máquina de radioterapia que a mediados de los 80 causó la muerte de tres de los seis pacientes que recibieron una sobredosis de radiación a causa de una serie de errores tanto en el software que controlaba la máquina como en el diseño de esta, que confiaba demasiado en este control por software sin que este hubiera sido probado al cien por cien.
Es cierto que el error era difícil de localizar y que sólo se producía si se introducía una serie de comandos en la consola de control del aparato en una secuencia determinada y en menos de ocho segundos, pero esto no es disculpa, y menos en un sistema del que no sólo depende la curación de unos enfermos, sino que, como se vio, puede matarlos.
El caso del Therac-25, por cierto, suena muy parecido al del acelerador de partículas del hospital Clínico de Zaragoza, donde a principios de los 90 fallecieron otros tres pacientes por sobredosis de radiación, aunque en este caso el problema estuvo en una manipulación inadecuada del aparato por parte de un técnico de mantenimiento, que puenteó diversos mecanismos de seguridad de la máquina.
Otro caso tristemente célebre en el que un error de software causó varias muertes fue el ocurrido el 25 de febrero de 1991, durante la primera guerra del Golfo, cuando una batería antimisiles Patriot no derribó un misil Scud iraquí a pesar de haberlo detectado.
En este caso el problema era que el error en cuestión hacía que el reloj interno del sistema antimisiles no mantuviera la hora correctamente, con lo que en el momento del ataque el error acumulado era de un tercio de segundo.
Este error, que parece pequeño, hizo que aunque el radar detectara perfectamente el misil Scud, al intentar seguir su trayectoria esperara encontrarlo en otro sitio. Como no estaba allí, sino a unos 600 metros de distancia, que era la velocidad que recorría en ese tercio de segundo, el software de control interpretó que la detección del radar había sido un error y no disparó los misiles interceptores.
Como consecuencia, 28 soldados murieron a causa del impacto.
Lo peor de este caso es que tanto el fabricante de los misiles como el ejército de los Estados Unidos conocían la existencia de este error, que había sido detectado por el ejército israelí, y aunque para evitar sus efectos bastaba con reiniciar los ordenadores de las baterías Patriot cada cierto tiempo, nadie parecía tener muy claro cual era este intervalo.
Curiosamente, al día siguiente a este incidente, el fabricante de los Patriot entregó una versión actualizada del software que corregía este error al ejército.
Un bug encontrado en un ordenador
Otros incidentes notables a causa de errores del software fueron la pérdida del primer cohete Ariane 5 de la Agencia Espacial Europea o la de la sonda Mars Global Surveyor de la NASA, aunque como incidente espectacular y que afectó a miles de personas fue la caída de la red de llamadas a larga distancia de AT&T en los Estados Unidos el 15 de enero de 1990.
En aquella ocasión, uno de los ordenadores que controlaban el sistema, denominados 4ESS, detectó un fallo en su propio funcionamiento y procedió a reiniciarse, tal y como estaba programado. Al mismo tiempo, envió una señal a los ordenadores a los que estaba conectado directamente indicándoles de que se estaba reiniciando. Pero los otros 4ESS, una vez avisados de esto, y de nuevo por un error de software, no supieron interpretar correctamente la señal que decía que el primero volvía a estar disponible, lo que hizo que a su vez se reiniciaran, lo que hizo que el fallo se extendiera en cascada por toda la red, que estuvo inoperativa durante unas nueve horas.
Evitar este tipo de problemas es precisamente uno de los campos de trabajo de la llamada ingeniería del software, que en general busca desarrollar métodos para racionalizar todo el proceso de desarrollo de este y para asegurarse de que el software creado con la aplicación de estos métodos cumple con su cometido sin incluir errores, y es una disciplina a la que, lógicamente, cada vez se le está dando más importancia.
En cualquier caso, a estas alturas, creo que no nos queda más remedio que aceptar que hemos de vivir con la realidad de un software imperfecto porque en general nuestro mundo sería mucho peor sin él.
- Los diez peores bugs de la historia, una lista de 2005 que incluye algunos de los aquí citados.
