Uno de los fallos más grandes de software que se recuerdan fue el que afectó al acelerador lineal médico modelo Therac-25. Esta máquina -que costaba 1 millón de dólares- se usaba para tratar a pacientes de cáncer con radioterapia y, debido a un error de software, costó la vida a 6 personas entre los años 1985 y 1987.
Este modelo, fabricado conjuntamente por la empresa AECL (Atomic Energy of Canada Limited) y CGR (una empresa francesa) era la versión modernizada de su anterior y popular modelo el Therac-20. Estas máquinas aceleran los electrones y los enfocan en los tumores para destruirlos.
Para penetración de baja intensidad en tejidos se usaban haces de electrones, y para alcanzar tumores más internos el haz se convertía en rayos-X. Para ello se lanzaba un haz de electrones de alta potencia (¡25 millones de electron-voltios!) y se insertaba una placa metálica (de número atómico alto, tipo Tungsteno) entre el haz y el paciente.
Desde una habitación contigua blindada, la máquina se controlaba mediante un programa de ordenador de modo que el operador no estuviese nunca expuesto a la radiación. Además se confiaba por completo en el software para "evitar errores humanos".
Lo que ocurrió es que, debido a un fallo en el software de control, en ocasiones se exponía a los pacientes al haz de alta intensidad sin la protección intermedia de la placa metálica, causando una exposición a dosis letales de radiación (100 veces mayores de lo esperado) y acabando con la vida de estos meses más tarde. Los anteriores modelos tenían un control mecánico y por hardware que detectaba si estaba o no puesta la placa impidiendo activar el haz de alta intensidad si no era así. En el Therac-25 esto se dejó al criterio del software, que no detectaba bien esto debido a una condición de carrera en el programa. Para simplificarlo digamos que si el operador humano era muy rápido dándole al teclado, como había un contador de 1 byte que desbordaba, si la orden coincidía con ese momento no se detectaba la ausencia de la placa y se lanzaba el haz igual.
Las conclusiones de las investigaciones realizadas sobre el asunto fueron que, más que un error del software en concreto, lo que llevó a esta situación fue un mal diseño del software y unas prácticas de desarrollo inadecuadas, que entre otras cosas impedían poder automatizar las pruebas de la lógica del programa. Casi nada. Además había mensajes de error poco claros hacia los operadores (todo un clásico), y como se depositaba tanta confianza en el software, tanto los operadores como los programadores no creyeron a los primeros pacientes que se quejaron, diciéndoles que eran cosas suyas (otro clásico: demasiada confianza en el software).
En este interesante artículo de la Wikipedia puedes encontrar información detallada sobre este caso, y además tienes en YouTube una clase grabada de la Univerdad de Berkeley (en inglés) en la que el profesor Brian Harvey dedica casi una hora a discutir el caso y todas sus ramificaciones.
Y es que el software es cada vez más importante, pero cuando va en máquinas que afectan directa y físicamente a las personas, la importancia de una buena base, un buen método de trabajo y unas buenas prácticas de testing es crucial.