El otro día, revisando material para un artículo, me encontré con aquella lista de los diez peores bugs de la historia: desastres catastróficos de la industria del software que causaron daños terribles, en unas ocasiones pérdidas de vidas, en otras de millones y millones en equipamiento o tiempo perdido. Todas son historias de las que hay mucho para aprender y sobre lo que meditar, y que además permiten apreciar cómo ha reaccionado la industria del software con el paso del tiempo.
Entre el tipo de bugs o fallos que causan estos desastres se enmarcaban en su día básicamente cuatro: errores de programación que acaban de forma espectacular (cohetes, sondas espaciales, aviones u otros ingenios que chocan o explotan); errores en las dosis que aparatos de usos médicos suministran a los pacientes (normalmente radiación); fallos en software comercial o industrial que acaba repercutiendo en los usuarios finales (chips que se equivocan al dividir, que hay que reemplazar) y fallos de software en equipamiento del que dependen redes y que causan desastres como caídas de servicios debido a un «efecto red».
Gran parte de este software no es el que instalamos en los ordenadores: es el que va incluido en el firmware de los aparatos que conviven con nosotros cada día. A medida que avanzan en sofisticación, cada aparato que nos rodea deja de ser un poco «mecánico» para pasar a estar controlado por microprocesadores. Hoy en día los aviones, coches, edificios inteligentes, los semáforos de las ciudades y los sistemas de suministro de energía, agua y muchos más están altamente informatizados. En un coche, por ejemplo, puede haber hasta unos 70 procesadores controlando individualmente tareas como los frenos ABS, los airbags, el control de crucero o el suministro de combustible. Todo ello son pequeños programas diseñados para realizar tareas autónomas, y todos son propensos a fallos.
Lo peor de este tipo de bugs es que eliminarlos completamente es sencillamente imposible. La teoría dice que no se puede probar un programa de forma tan extensa como para eliminar totalmente la posibilidad de fallos: se pueden realizar simulaciones de todo tipo y hacerlo funcionar en condiciones extremas, pero nunca se podrá saber si en algún momento va a fallar por algo imprevisto. (La clave aquí es que no se puede «prever lo imprevisible»). En realidad, es mucho más práctico seguir unas buenas pautas en las técnicas de desarrollo que garanticen la calidad de ese software a cada paso, hacer todas las pruebas pertinentes y luego un buen seguimiento de todos los sistemas en condiciones reales.
En The Day the Phones Stopped Ringing (El día en que los teléfonos dejaron de funcionar, 1992) Leonard Lee describía, al igual que la lista de los bugs, algunos de los fallos más clamorosos de las primeras décadas de la computerización masiva: máquinas de hospital descontroladas, aviones de combate que quedaban destruidos por fallos en los sistemas de identificación amigo-enemigo y las nueve horas que la red de AT&T estuvo caída en 1990 debido a un fallo en cascada, hecho que dio título al libro. Ahora que han pasado dos décadas desde su publicación, los consumidores de todo el planeta contamos con máquinas mucho más sofisticadas y computerizadas que por aquel entonces. También han mejorado los controles, pero las situaciones «complicadas» debido a problemas de programación siguen estando ahí.
Diversos bugs hicieron en las últimas décadas que se perdieran más cohetes y sondas espaciales, entre ellos el Mariner 1, el Ariane 5 y el Mars Climate Orbiter. El más «doloroso» de los bugs fue tal vez un malentendido de conversión entre unidades imperiales y métricas que hizo que la Mars Climate se estampara contra Marte, literalmente. Los coches modernos, cada vez más automatizados, tampoco están exentos de problemas: algunos modelos han tenido fallos en su software que ha requerido que fueran devueltos a la fábrica. Y cuando el propietario convencido de que es un fallo de software es el legendario «Woz» (Steve Wozniak, co-fundador de Apple), más vale fiarse. El otro día los investigadores dejaban caer que los vehículos modernos pueden ser propensos a ataques informáticos, algo que aunque ahora pueda parecer lejano tal vez en cinco o diez años sea una auténtica preocupación del día a día, como hoy son los virus informáticos.
Otro tipo de fallos que han empezado a llamar la atención han sido diversos desastres en cuestiones de privacidad, pérdida de datos y similares. Un fallo en una actualización de T-Mobile y Microsoft hizo que miles de clientes perdieran sus agendas de contactos, notas, calendarios y fotos, que residían en un servidor central y no en sus terminales personales. El hecho de que Amazon pudiera entrar a borrar datos en los lectores de libros Kindle de los usuarios también levantó algunas alarmas, pues no parece normal que alguien entre en tu casa a llevarse un libro que ya habías comprado: un bug en esos sistemas podría hacer que contenidos o software comprado para libros electrónicos o teléfonos móviles desapareciera sin dejar rastro.
Tal vez el más genuino y espectacular de los bugs de los últimos meses, causado esta vez por un solo carácter en una línea de código (faltaba un punto), fue el que hizo desaparecer a Suecia del mapa de Internet durante horas, que se convirtieron en días para algunos proveedores. La gente simplemente no podía acceder a ninguna página web alojada en el dominio de Suecia (.se) porque el servicio de nombres pensaba que no existían. Esto definitivamente hubiera servido para poner al día el título de aquel libro sobre el fallo de AT&T y su red telefónica, una especie de El día en que parte de Internet dejó de existir.
{Foto (CC) hegemonx}
Este artículo se publicó originalmente en Cooking Ideas, un blog de Vodafone donde colaboramos semanalmente con el objetivo de crear historias que «alimenten la mente de ideas».
