Error de software

Un error de software es un error en el software de la computadora .

Un programa de computadora con muchos o graves errores puede ser descrito como "defectuoso" .

Los efectos de un error de software varían desde menores (como una palabra mal escrita en la interfaz de usuario ) hasta graves (como fallas frecuentes ).

Los errores de software se han relacionado con desastres. Los errores de software en la máquina de radioterapia Therac-25 fueron directamente responsables de las muertes de pacientes en la década de 1980. En 1996, el prototipo de cohete Ariane 5 de la Agencia Espacial Europea , valorado en 1.000 millones de dólares, fue destruido menos de un minuto después del lanzamiento debido a un error en el programa informático de guía de a bordo. ^[1] En 1994, un helicóptero Chinook de la RAF se estrelló , matando a 29 personas; inicialmente se atribuyó a un error del piloto, pero más tarde se pensó que había sido causado por un error de software en el ordenador de control del motor . ^{[2] El software con errores provocó el} escándalo de la Oficina Postal Británica de principios del siglo XXI . ^[3]

En 2002, un estudio encargado por el Instituto Nacional de Estándares y Tecnología del Departamento de Comercio de Estados Unidos concluyó que "los errores de software son tan frecuentes y tan perjudiciales que cuestan a la economía estadounidense unos 59.000 millones de dólares anuales, o alrededor del 0,6 por ciento del producto interno bruto". ^[4]

Desde la década de 1950, algunos sistemas informáticos han sido diseñados para detectar o corregir automáticamente diversos errores de software durante sus operaciones.

El metamorfismo de errores (del griego meta = "cambio", morph = "forma") se refiere a la evolución de un defecto en la etapa final de la implementación de un software. La transformación de un "error" cometido por un analista en las primeras etapas del ciclo de vida del desarrollo de software, que conduce a un "defecto" en la etapa final del ciclo, se ha denominado 'metamorfismo de errores'. ^[5]

Las diferentes etapas de un error en el ciclo de desarrollo pueden describirse como equivocación, ^{[6] : 31} anomalía, ^{[6] : 10} falla, ^{[6] : 31} falla, ^{[6] : 31} error, ^{[6] : 31} excepción, ^{[6] : 31} caída, ^{[6] : 22} falla, bug, ^{[6] : 14} defecto, incidente, ^{[6] : 39} o efecto secundario.

A veces, el uso de la palabra "bug" para describir el comportamiento del software es polémico debido a la percepción. Algunos sugieren que se debería abandonar el término y reemplazarlo por "defecto" o "error" .

Algunos sostienen que el término error implica que el defecto surgió por sí solo y presionan para que se utilice en su lugar el término defecto, ya que connota más claramente que fue causado por un ser humano. ^[7]

Algunos sostienen que el error puede utilizarse para encubrir una decisión de diseño intencional. En 2011, después de recibir el escrutinio del senador estadounidense Al Franken por registrar y almacenar las ubicaciones de los usuarios en archivos no cifrados, ^[8] Apple calificó el comportamiento como un error. Sin embargo, Justin Brookman, del Centro para la Democracia y la Tecnología, cuestionó directamente esa descripción, afirmando: "Me alegra que estén solucionando lo que llaman errores, pero no estoy de acuerdo con su rotunda negación de que rastreen a los usuarios". ^[9]

Prevenir errores lo más pronto posible en el proceso de desarrollo de software es un objetivo de inversión e innovación. ^{[10] [11]}

Los lenguajes de programación más nuevos tienden a estar diseñados para evitar errores comunes basados ​​en vulnerabilidades de lenguajes existentes. Las lecciones aprendidas de lenguajes más antiguos, como BASIC y C, se utilizan para informar el diseño de lenguajes posteriores, como C# y Rust .

Los lenguajes pueden incluir características como un sistema de tipos estáticos, espacios de nombres restringidos y programación modular . Por ejemplo, para un lenguaje compilado y tipado (como C ):

número flotante = "3";

es sintácticamente correcto, pero no supera la comprobación de tipos, ya que el lado derecho, una cadena, no se puede asignar a una variable de punto flotante. La compilación falla, lo que obliga a corregir este defecto antes de que se pueda reanudar el progreso del desarrollo. Con un lenguaje interpretado, no se produciría un error hasta más tarde, en el tiempo de ejecución.

Algunos lenguajes excluyen características que fácilmente conducen a errores, a costa de un rendimiento más lento; el principio es que, por lo general, es mejor escribir código más simple, más lento y correcto que código complicado y lleno de errores. Por ejemplo, Java no admite la aritmética de punteros, que, por lo general, es rápida, pero se considera peligrosa; es relativamente fácil provocar un error importante.

Algunos lenguajes incluyen funciones que agregan sobrecarga de tiempo de ejecución para evitar algunos errores. Por ejemplo, muchos lenguajes incluyen una verificación de límites de tiempo de ejecución y una forma de manejar condiciones fuera de límites en lugar de fallas.

Un lenguaje compilado permite detectar algunos errores tipográficos (como un identificador mal escrito) antes del tiempo de ejecución , lo cual ocurre antes en el proceso de desarrollo de software que en el caso de un lenguaje interpretado .

Las técnicas de programación como el estilo de programación y la programación defensiva tienen como objetivo evitar errores tipográficos.

Por ejemplo, un error puede deberse a un error tipográfico relativamente menor (error tipográfico) en el código. Por ejemplo, este código ejecuta una función foosolo si conditiones verdadero.

si (condición) foo();

Pero este código siempre se ejecuta foo:

si (condición); foo();

Una convención que tiende a prevenir este problema en particular es requerir llaves para un bloque incluso si tiene solo una línea.

si (condición) { foo();}

La aplicación de las convenciones puede ser manual (es decir, mediante revisión de código ) o mediante herramientas automatizadas.

Algunos sostienen que escribir una especificación de programa que establezca el comportamiento de un programa puede prevenir errores.

Algunos sostienen que las especificaciones formales son poco prácticas excepto para los programas más cortos, debido a problemas de explosión combinatoria e indeterminación .

Uno de los objetivos de las pruebas de software es encontrar errores.

Las mediciones durante las pruebas pueden proporcionar una estimación de la cantidad de errores que probablemente persistan. Esto se vuelve más confiable cuanto más tiempo se prueba y desarrolla un producto. ^{[ cita requerida ]}

El desarrollo ágil de software puede implicar lanzamientos frecuentes de software con cambios relativamente pequeños. Los defectos se revelan mediante la retroalimentación de los usuarios.

Con el desarrollo basado en pruebas (TDD), las pruebas unitarias se escriben mientras se escribe el código de producción, y el código de producción no se considera completo hasta que todas las pruebas se completen con éxito.

Las herramientas para el análisis de código estático ayudan a los desarrolladores a inspeccionar el texto del programa más allá de las capacidades del compilador para detectar problemas potenciales. Aunque en general el problema de encontrar todos los errores de programación dada una especificación no tiene solución (ver problema de detención ), estas herramientas explotan el hecho de que los programadores humanos tienden a cometer ciertos tipos de errores simples a menudo al escribir software.

Las herramientas para supervisar el rendimiento del software mientras se ejecuta, ya sea específicamente para encontrar problemas como cuellos de botella o para garantizar que funciona correctamente, pueden estar incorporadas en el código de forma explícita (tal vez de forma tan sencilla como una declaración que diga PRINT "I AM HERE"), o pueden proporcionarse como herramientas. A menudo resulta sorprendente descubrir dónde se dedica la mayor parte del tiempo a un fragmento de código, y esta eliminación de suposiciones puede hacer que se reescriba el código.

El desarrollo de código abierto permite que cualquiera pueda examinar el código fuente. Una escuela de pensamiento popularizada por Eric S. Raymond como la ley de Linus dice que el software de código abierto popular tiene más posibilidades de tener pocos o ningún error que otro software, porque "si se le dan suficientes ojos, todos los errores son superficiales". ^[12] Sin embargo, esta afirmación ha sido cuestionada: el especialista en seguridad informática Elias Levy escribió que "es fácil ocultar vulnerabilidades en código fuente complejo, poco comprendido y no documentado", porque "incluso si la gente está revisando el código, eso no significa que estén calificados para hacerlo". ^[13] Un ejemplo de un error de software de código abierto fue la vulnerabilidad OpenSSL de 2008 en Debian .

La depuración puede ser una parte importante del ciclo de vida del desarrollo de software . Maurice Wilkes , uno de los pioneros de la informática, describió su descubrimiento a finales de la década de 1940 de que “gran parte del resto de mi vida la iba a pasar buscando errores en mis propios programas”. ^[14]

Un programa conocido como depurador puede ayudar a un programador a encontrar código defectuoso examinando el funcionamiento interno de un programa, como ejecutar el código línea por línea y visualizar los valores de las variables.

Como alternativa al uso de un depurador, el código puede instrumentarse con lógica para generar información de depuración con el fin de rastrear la ejecución del programa y visualizar los valores. La salida suele ser a una consola , una ventana , un archivo de registro o una salida de hardware (es decir, un LED ).

Algunos sostienen que localizar un error es todo un arte.

No es raro que un error en una sección de un programa provoque fallos en otra sección, ^{[ cita requerida ]} lo que dificulta su seguimiento, en una parte aparentemente no relacionada del sistema. Por ejemplo, un error en una rutina de representación de gráficos que provoque un error en una rutina de entrada/salida de archivos.

A veces, la parte más difícil de la depuración es encontrar la causa del error. Una vez encontrada, corregir el problema a veces es fácil, por no decir trivial.

A veces, un error no es un defecto aislado, sino que representa un error de pensamiento o planificación por parte de los programadores. A menudo, un error lógico de este tipo requiere que se revise o reescriba una sección del programa.

Algunos sostienen que, como parte de la revisión del código , recorrerlo e imaginar o transcribir el proceso de ejecución a menudo puede encontrar errores sin llegar a reproducir el error como tal.

Por lo general, el primer paso para localizar un error es reproducirlo de forma fiable. Si no se puede reproducir el problema, un programador no puede encontrar la causa del error y, por lo tanto, no puede solucionarlo.

Algunos errores se revelan mediante entradas que pueden resultar difíciles de recrear para el programador. Una de las causas de las muertes de la máquina de radiación Therac-25 fue un error (específicamente, una condición de carrera ) que se produjo solo cuando el operador de la máquina introdujo muy rápidamente un plan de tratamiento; se necesitaron días de práctica para poder hacer esto, por lo que el error no se manifestó en las pruebas o cuando el fabricante intentó duplicarlo. Otros errores pueden dejar de ocurrir siempre que se amplíe la configuración para ayudar a encontrar el error, como ejecutar el programa con un depurador; estos se denominan errores de Heisen (nombre humorístico que hace referencia al principio de incertidumbre de Heisenberg ).

Desde la década de 1990, en particular después del desastre del vuelo 501 del Ariane 5 , aumentó el interés en las ayudas automatizadas para la depuración, como el análisis de código estático mediante interpretación abstracta . ^[15]

A menudo, los errores surgen durante la codificación, pero una documentación de diseño defectuosa puede provocar un error. En algunos casos, los cambios en el código pueden eliminar el problema aunque el código ya no coincida con la documentación.

En un sistema integrado , el software a menudo se modifica para solucionar un error de hardware, ya que es más económico que modificar el hardware.

Los errores se gestionan mediante actividades como documentar, categorizar, asignar, reproducir, corregir y publicar el código corregido.

A menudo se utilizan herramientas para rastrear errores y otros problemas con el software. Por lo general, el equipo de desarrollo de software utiliza herramientas diferentes para rastrear su carga de trabajo que el servicio de atención al cliente para rastrear los comentarios de los usuarios . ^[16]

A un elemento rastreado se le suele llamar error , defecto , ticket , problema , característica o, en el caso del desarrollo ágil de software , historia o épica . Los elementos suelen clasificarse por aspectos como gravedad, prioridad y número de versión .

En un proceso que a veces se denomina triage , se toman decisiones para cada error sobre si se debe corregir y cuándo hacerlo en función de información como la gravedad y la prioridad del error y factores externos como los cronogramas de desarrollo. El triage generalmente no incluye la investigación de la causa. El triage puede realizarse con regularidad. El triage generalmente consiste en revisar los errores nuevos desde el triage anterior y tal vez todos los errores abiertos. Los asistentes pueden incluir al gerente de proyecto, al gerente de desarrollo, al gerente de pruebas, al gerente de compilación y a expertos técnicos. ^{[17] [18]}

La gravedad es una medida del impacto que tiene el error. ^[19] Este impacto puede ser pérdida de datos, financiera, pérdida de buena voluntad y esfuerzo desperdiciado. Los niveles de gravedad no están estandarizados, sino que difieren según el contexto, como la industria y la herramienta de seguimiento. Por ejemplo, una falla en un videojuego tiene un impacto diferente a una falla en un servidor bancario. Los niveles de gravedad pueden ser falla o bloqueo , sin solución alternativa (el usuario no puede realizar una tarea), tiene solución alternativa (el usuario aún puede realizar la tarea), defecto visual (un error ortográfico, por ejemplo) o error de documentación . Otro ejemplo de conjunto de gravedades: crítico , alto , bajo , bloqueador , trivial . ^[20] La gravedad de un error puede ser una categoría separada de su prioridad para corregir, o las dos pueden cuantificarse y gestionarse por separado.

Un error lo suficientemente grave como para retrasar el lanzamiento del producto se denomina " show stopper" . ^{[21] [22]}

La prioridad describe la importancia de resolver el error en relación con otros errores. Las prioridades pueden ser numéricas, como del 1 al 5, o con nombre, como crítico , alto , bajo y diferido . Los valores pueden ser similares o idénticos a las clasificaciones de gravedad, aunque la prioridad sea un aspecto diferente.

La prioridad puede ser una combinación de la gravedad del error y el nivel de esfuerzo necesario para solucionarlo. Un error de baja gravedad pero fácil de solucionar puede tener mayor prioridad que un error de gravedad moderada que requiera mucho más esfuerzo para solucionarlo.

Los errores que tienen una prioridad suficientemente alta pueden justificar un lanzamiento especial, a veces llamado parche .

Una versión de software que enfatiza la corrección de errores puede denominarse versión de mantenimiento , para diferenciarla de una versión que enfatiza nuevas características u otros cambios.

Es una práctica habitual lanzar software con errores conocidos y de baja prioridad u otros problemas. Las posibles razones incluyen, entre otras:

• Se debe cumplir una fecha límite y los recursos no son suficientes para corregir todos los errores antes de la fecha límite ^[23]

• El error ya está corregido en una próxima versión y no es de alta prioridad.

• Los cambios necesarios para corregir el error son demasiado costosos o afectan a muchos otros componentes, lo que requiere una importante actividad de prueba.

• Se puede sospechar o saber que algunos usuarios confían en el comportamiento con errores existente; una solución propuesta puede introducir un cambio radical.

• El problema está en un área que quedará obsoleta con una próxima versión; arreglarlo no es necesario

• "No es un error, es una característica" ^[24] Existe un malentendido entre el comportamiento esperado y el real o una característica no documentada

La cantidad y el tipo de daño que puede causar un error de software afectan la toma de decisiones, los procesos y las políticas en materia de calidad del software. En aplicaciones como los vuelos espaciales tripulados , la aviación , la energía nuclear , la atención sanitaria , el transporte público o la seguridad de los automóviles , dado que los fallos de software tienen el potencial de causar lesiones o incluso la muerte a personas, dicho software tendrá un escrutinio y un control de calidad mucho mayores que, por ejemplo, un sitio web de compras en línea. En aplicaciones como la banca, donde los fallos de software tienen el potencial de causar graves daños financieros a un banco o a sus clientes, el control de calidad también es más importante que, por ejemplo, en una aplicación de edición de fotografías.

Además del daño que causan los errores, parte de su costo se debe al esfuerzo invertido en corregirlos. En 1978, Lientz et al. demostraron que la media de los proyectos invierte el 17 por ciento del esfuerzo de desarrollo en la corrección de errores. ^[25] En 2020, una investigación sobre los repositorios de GitHub mostró que la media es del 20 %. ^[26]

En 1994, el Centro de Vuelo Espacial Goddard de la NASA logró reducir su número promedio de errores de 4,5 por 1000 líneas de código ( SLOC ) a 1 por 1000 SLOC. ^[27]

Otro estudio de 1990 informó que los procesos de desarrollo de software excepcionalmente buenos pueden lograr tasas de fallas de implementación tan bajas como 0,1 por 1000 SLOC. ^[28] Esta cifra se repite en la literatura como Code Complete de Steve McConnell , ^[29] y el estudio de la NASA sobre la complejidad del software de vuelo . ^[30] Algunos proyectos incluso alcanzaron cero defectos: el firmware de la máquina de escribir IBM Wheelwriter , que consta de 63 000 SLOC, y el software del transbordador espacial con 500 000 SLOC. ^[28]

Para facilitar la investigación reproducible sobre pruebas y depuración, los investigadores utilizan puntos de referencia seleccionados de errores:

• El punto de referencia de Siemens
• ManyBugs ^[31] es un punto de referencia de 185 errores de C en nueve programas de código abierto.
• Defects4J ^[32] es un banco de pruebas de 341 errores de Java de 5 proyectos de código abierto. Contiene los parches correspondientes, que cubren una variedad de tipos de parches.

Algunos tipos de errores notables:

Un error puede deberse a un diseño insuficiente o incorrecto según la especificación. Por ejemplo, dado que la especificación consiste en ordenar alfabéticamente una lista de palabras, puede producirse un error de diseño si el diseño no tiene en cuenta los símbolos, lo que daría como resultado una ordenación alfabética incorrecta de palabras con símbolos.

Las operaciones numéricas pueden generar resultados inesperados, procesamiento lento o fallas. ^[33] Un error de este tipo puede deberse a una falta de conocimiento de las cualidades del almacenamiento de datos, como una pérdida de precisión debido al redondeo , algoritmos numéricamente inestables , desbordamiento y subdesbordamiento aritmético , o por falta de conocimiento de cómo se manejan los cálculos mediante diferentes lenguajes de codificación de software, como la división por cero , que en algunos lenguajes puede generar una excepción y en otros puede devolver un valor especial como NaN o infinito .

Un error de flujo de control , también conocido como error lógico, se caracteriza por un código que no falla con un error, pero no tiene el comportamiento esperado, como un bucle infinito , una recursión infinita , una comparación incorrecta en un condicional como usar el operador de comparación incorrecto y el error de un dígito .

• Uso incorrecto de API.
• Implementación de protocolo incorrecta.
• Manejo incorrecto del hardware.
• Suposiciones incorrectas de una plataforma particular.
• Sistemas incompatibles . Una nueva API o protocolo de comunicaciones puede parecer que funciona cuando dos sistemas utilizan versiones diferentes, pero pueden producirse errores cuando una función o característica implementada en una versión se modifica o falta en otra. En sistemas de producción que deben funcionar continuamente, puede que no sea posible apagar todo el sistema para una actualización importante, como en la industria de las telecomunicaciones ^[34] o Internet. ^{[35] [36] [37]} En este caso, los segmentos más pequeños de un sistema grande se actualizan individualmente, para minimizar las interrupciones en una red grande. Sin embargo, algunas secciones podrían pasarse por alto y no actualizarse, y causar errores de compatibilidad que pueden ser difíciles de encontrar y reparar.
• Anotaciones de código incorrectas.

• Punto muerto : una tarea no puede continuar hasta que una segunda termine, pero al mismo tiempo, la segunda no puede continuar hasta que la primera termine.
• Condición de carrera : múltiples tareas simultáneas compiten por recursos.
• Errores en secciones críticas , exclusiones mutuas y otras características del procesamiento concurrente . El tiempo de verificación hasta el tiempo de uso (TOCTOU) es una forma de sección crítica desprotegida.

• Desreferencia de puntero nulo .
• Usando una variable no inicializada .
• Utilizando una instrucción que de otro modo sería válida en un tipo de datos incorrecto (ver decimal empaquetado / decimal codificado en binario ).
• Violaciones de acceso .
• Fugas de recursos, donde un recurso finito del sistema (como la memoria o los identificadores de archivos ) se agota debido a una asignación repetida sin liberación.
• Desbordamiento de búfer , en el que un programa intenta almacenar datos más allá del límite de almacenamiento asignado. Esto puede o no provocar una violación de acceso o de almacenamiento . Estos suelen ser errores de seguridad .
• Recursión excesiva que, aunque lógicamente válida, provoca un desbordamiento de pila .
• Error de uso después de liberación, donde se utiliza un puntero después de que el sistema ha liberado la memoria a la que hace referencia.
• Doble error libre.

• Uso del token incorrecto , como realizar una asignación en lugar de una prueba de igualdad . Por ejemplo, en algunos lenguajes x=5 establecerá el valor de x en 5, mientras que x==5 comprobará si x es actualmente 5 o algún otro número. Los lenguajes interpretados permiten que este tipo de código falle. Los lenguajes compilados pueden detectar estos errores antes de que comience la prueba.

• Actualizaciones no propagadas; por ejemplo, el programador cambia "myAdd" pero olvida cambiar "mySubtract", que utiliza el mismo algoritmo. Estos errores se mitigan con la filosofía Don't Repeat Yourself (No repetirse ).
• Comentarios desactualizados o incorrectos: muchos programadores asumen que los comentarios describen con precisión el código.
• Diferencias entre documentación y producto.

En agosto de 2016, el Open Technology Institute, dirigido por el grupo New America , ^{[38] publicó un informe titulado "Bugs in the System" (Errores en el sistema), en el que se afirma que los responsables de las políticas estadounidenses deberían realizar reformas para ayudar a los investigadores a identificar y abordar los errores de software. El informe "destaca la necesidad de reformas en el campo del descubrimiento y la divulgación de vulnerabilidades de software". [39]} Uno de los autores del informe dijo que el Congreso no ha hecho lo suficiente para abordar la vulnerabilidad del software cibernético, a pesar de que el Congreso ha aprobado una serie de proyectos de ley para combatir el problema más amplio de la ciberseguridad. ^[39]

Los investigadores gubernamentales, las empresas y los expertos en seguridad cibernética son los que suelen descubrir los fallos de software. El informe pide reformar las leyes sobre delitos informáticos y derechos de autor. ^[39]

La Ley de Abuso y Fraude Informático, la Ley de Derechos de Autor del Milenio Digital y la Ley de Privacidad de las Comunicaciones Electrónicas penalizan y crean sanciones civiles para acciones que los investigadores de seguridad realizan rutinariamente mientras realizan investigaciones de seguridad legítimas, señala el informe. ^[39]

• En los videojuegos, el término " fallo " se utiliza a veces para referirse a un error de software. Un ejemplo es el fallo y la especie no oficial de Pokémon MissingNo.
• Tanto en la novela de 1968 2001: Una odisea del espacio como en la película correspondiente del mismo nombre , la computadora a bordo de la nave espacial, HAL 9000 , intenta matar a todos los miembros de su tripulación. En la novela de seguimiento de 1982, 2010: Odisea dos , y la película que la acompaña de 1984, 2010: El año en que hacemos contacto , se revela que esta acción fue causada por la computadora que había sido programada con dos objetivos conflictivos: revelar completamente toda su información y mantener en secreto el verdadero propósito del vuelo de la tripulación; este conflicto hizo que HAL se volviera paranoico y eventualmente homicida.
• En la versión en inglés de la canción de Nena de 1983 99 Luftballons (99 globos rojos), como resultado de "errores en el software", el lanzamiento de un grupo de 99 globos rojos se confunde con el lanzamiento de un misil nuclear enemigo, lo que requiere una respuesta de lanzamiento equivalente y resulta en una catástrofe.
• En la comedia estadounidense de 1999 Office Space , tres empleados intentan (sin éxito) explotar la preocupación de su empresa por el error informático Y2K utilizando un virus informático que envía fracciones redondeadas de un centavo a su cuenta bancaria, una técnica conocida desde hace mucho tiempo y descrita como corte de salami .
• La novela The Bug (2004) , de Ellen Ullman , trata sobre el intento de un programador de encontrar un error esquivo en una aplicación de base de datos. ^[40]
• La película canadiense de 2008 Control Alt Delete trata sobre un programador informático que a finales de 1999 lucha por solucionar errores en su empresa relacionados con el problema del año 2000.

• Anti-patrón
• Corrección automática de errores
• Programa de recompensas por errores
• Eliminación de fallas
• Error de hardware
• ISO/IEC 9126 , que clasifica un error como un defecto o una no conformidad
• Lista de errores de software
• Clasificación de defectos ortogonales
• Problema de la pista de carreras
• Resumen de RIESGOS
• Sorpresa por un solo evento
• Indicador de defecto de software
• Regresión de software
• Podredumbre del software
• VUCA

MediaWiki tiene documentación relacionada con: Gestión de errores

• "Enumeración de debilidades comunes": una página web especializada en errores, en NIST.gov
• Tipo BUG de Jim Gray – otro tipo Bug
• Imagen del «primer error informático» en Wayback Machine (archivada el 12 de enero de 2015)
• "¡El primer error informático!": un correo electrónico de 1981 sobre el error del almirante Hopper
• "Hacia la comprensión de los errores de compilación en GCC y LLVM". Un estudio de 2016 sobre errores en compiladores