El primer bug conocido fue un bug físico. Literalmente. Una polilla entre los relés del Mark II causó errores en su funcionamiento allá por el 1947.

Por desgracia, en lugar de ser una excepción, encontrar errores en el software es un problema común. En muchos casos, estos errores son simplemente un fastidio sin graves consecuencias y que se arreglan con una nueva versión del software sin que haya que lamentar mayores daños.

Pero no hay que olvidar que el software está en todas partes y que un error en un software ofimático puede que nos acordemos de la madre del programador/a de turno pero un error en un software médico o de control de sistemas críticos puede tener consecuencias mucho más fatales.

Sin ánimo de ser catastrofista (y siguiendo con mi “manía” de la importancia de enseñar la historia de la informática), os animo a seguir leyendo esta lista de los peores errores de la historia del software. Fijaros especialmente en el porqué de los errores, a ver si así evitamos repetirlos. En cada error comentamos el desencadenante principal pero siempre vino acompañado de una cadena de fallos que a partir de ese error acabó generando el fatal desenlace. Y es que ésa es la gran dificultad en todo proceso de “debugging”. El error nunca es obvio y sólo aparece en condiciones muy específicas en las que muchas veces no hemos pensado (y por tanto no escribimos el test correspondiente).

La explosión del Ariane 5. Mil millones de dolares perdidos

Y un retraso en muchas de las investigaciones que debían llevarse a cabo en el cohete. ¿El problema? En gran parte, la reutilización de código.

Y es que  parte del código del Ariane 5 se reutilizó del Ariane 4. Y aunque los dos eran cohetes de la misma familia no eran exactamente iguales y lo que en uno no dió problemas acabo en desastre en el otro en menos de 40 segundos.

Técnicamente hablando el causante del error fue que en una parte del código se intentaba copiar una variable de 64 bits en una de 16 con el consiguiente error de overflow. Esto no había dado problemas en el Ariane 4 ya que por sus características la variable de 64 nunca tomaba un valor mayor que lo que cabía en 16 bits pero no así en el Ariane 5.

Un ejemplo carísimo de la típica excusa “en mi ordenador funciona”

Exceso de radiación en el Therac-25 mató a cinco pacientes

Nada peor que un bug que acaba provocando la muerte de personas. Este es el caso de la máquina de radiación Therac-25 que por un error en su software de control suministró un exceso de radiación a varios pacientes provocando la muerte de al menos cinco de ellos.

La causa está en errores en el control de la concurrencia de las diferentes rutinas que se ejecutaban en paralelo, entre ellos un problema “clásico”, una race condition que inducía la máquina a emitir radiación a potencia máxima si una determinada secuencia de eventos inesperados se producía.

Mars Climate Orbiter. El error de conversión que nos dejó sin fotos de Marte

El Mars Climate Orbiter tenía como misión fotografiar Marte durante años. Pero no llegó a enviar ni una. Y todo por un fallo tan “tonto” como un error de conversión. El sistema de control de la nave en la Tierra usaba el sistema métrico anglosajón mientras que el sistema de navegación de la nave esperaba valores en el sistema métrico decimal. Esto hizo que la trayectoria de la nave se acercara demasiado a Marte y acabará desintegrada por la fuerza de fricción atmosférica del planeta.

En este caso, el error tuvo su origen en el incumplimiento de los requisitos del sistema que especificaba que todo el software debía usar el sistema métrico decimal. Muy buen ejemplo de la importancia de cumplir (y testear) que la implementación del software cumple con su especificación.

Cuando desplegar la versión incorrecta del software a producción te cuesta más de 400 millones de dolares en 45 minutos

Éste es otro error clásico, que en este caso concreto costo al grupo Knight Capital 460 millones de dolares en menos de una hora. Y es que desplegar una nueva versión del software a producción siempre es una operación de riesgo, sobretodo en el caso de algoritmos de “trading” especializados en la compra-venta de acciones casi instantáneas.

Entre otros problemas, se les “olvidó” cambiar la configuración del algoritmo para decirle que iba a ejecutarse en producción en lugar de en modo “test” (donde, justamente para probar su comportamiento en condiciones extremas, se eliminaban muchas de las restricciones que tenían que regular su comportamiento). Y claro, el algoritmos se dedicó a comprar y vender alegremente sin evaluar las consecuencias.

El problema del año 2000. El “error” que dio de comer a muchos informáticos

No podemos acabar sin mencionar el error más mediático. Los que tenemos una cierta edad nos pasamos los últimos años del siglo XX años escuchando relatos apocalípticos que explicaban que el mundo se iba a parar en el año 2000 debido a la multitud de sistemas informáticos que iban a dejar de funcionar.

El problema era que muchos programas antiguos almacenaban la fecha usando sólo dos dígitos para el año, para así ahorrar espacio. Con lo que para ellos, el año 2000 sería 1900, lo que haría que, por ejemplo, jubilados dejaran de cobrar su pensión al rejuvenecer 100 años.

Al final el número de sistemas afectados fue bastante limitado, en gran parte por la previsión de muchas empresas que se aseguraron de revisar y actualizar sus sistemas.

Por eso mismo digo que este tipo de error habitual (una excesiva optimización que no previó los efectos negativos a largo plazo) al final tuvo un efecto beneficioso en nuestra profesión ya que fue uno de los causantes del crecimiento de empleo en informática alrededor de esos años. Y es que no hay mal que por bien no venga.

Y aún más errores

Errores graves hay (y habrá) muchos más. Para una lista más exhaustiva de errores podéis consultar esta entrada de la wikipedia o esta otra (más corta pero que explica mejor cada error) Pero creo que los citados anteriormente son, cada uno de ellos, ejemplos representativos de distintos tipos de situaciones que os encontraréis en algún momento (espero que con posibles consecuencias mucho más leves). ¡Que os sirvan de lección!

Ah, y que nadie se piense que los informáticos somos los únicos ingenieros que la pifian. Aquí tenéis una serie de televisión con errores garrafales de otros tipos de ingenieros que, normalmente, tienen mejor fama :-).