¿Es posible escribir software libre de errores? ¿Qué tan buenos somos para atrapar todas las posibles excepciones? ¿Debemos prestar más atención a cada escenario de excepción o falla? ¿Es ese el problema fundamental? ¿Eso merece su propia línea de trabajo?

Posible, si. Probable no.

Es completamente posible escribir software libre de errores. Pero debido a la naturaleza del software, es posible que no esté libre de errores por mucho tiempo. Por dos factores.

1) El software útil es a menudo complejo. Alguien podría escribir fácilmente una implementación sin errores de “hello world”. Pero a pesar de su falta de errores, proporciona poco o ningún valor. El software real que proporciona valor a las personas suele ser complejo. Y con esta creciente complejidad viene la probabilidad de errores. Por más que lo intente, las probabilidades son que cuanto más intente resolver un problema real, más probabilidades tendrá de encontrar errores.

2) Los dominios problemáticos son un objetivo móvil. Lo que sucede a menudo, para consternación de los implementadores originales, es que el software se usa (¿se abusa?) Mucho más allá de su función prevista. O para decirlo de otra manera … Puede escribir software libre de errores, pero esencialmente tiene un nivel de frescura que solo puede disminuir con el tiempo. Libre de errores a partir de septiembre de 2012. ¿Qué sucede en el tercer trimestre de 2013 cuando el marco que usó está en desuso? ¿O cuando la gente cambia de plataforma y ahora tienes problemas de tracción? ¿O su software está retorcido para hacer algo para lo que no fue diseñado? Ahora su software, aunque no ha cambiado, tiene “errores”.

Entonces, un software libre de errores, aunque es bueno pensarlo, parece ser un mañana que nunca llegará. Puede obtener más información sobre la corrección del software académico al mirar cosas como el “problema de detención”. Hay personas por ahí que creen que podemos escapar de los bichos. Y para una determinada clasificación de errores, probablemente pueda.

Pero creo que, para el software que resuelve problemas y se ensucia con el cambio de estado y es escrito por personas promedio y se ajusta a los límites de los presupuestos … Los errores son solo una realidad que la gente tendrá que aceptar.

Hay mejores prácticas que uno puede emplear para reducir la probabilidad de que aparezcan errores. Pero estar absolutamente libre de errores por siempre jamás es poco probable.

Un error en el software generalmente se define en relación con alguna especificación de lo que debe hacer el software: un error es cuando la implementación se desvía de la especificación. Pero las especificaciones en sí mismas suelen tener errores o estar incompletas. Los investigadores de ingeniería de software han trabajado durante muchos años en lenguajes y herramientas para ayudar a los diseñadores a encontrar errores de especificación, por ejemplo, Alloy Analyzer:

http://alloy.mit.edu/alloy/

Yo diría que el software libre de errores realmente requiere una implementación y especificación correctas. Dadas las dificultades de escribir una especificación correcta, parece que por ahora, el software libre de errores está limitado a dominios muy estrechos. Dicho esto, ha habido un progreso reciente en esta área, particularmente en dominios donde una especificación correcta es más fácil (aunque todavía no es trivial) de escribir. Ver, por ejemplo, el compilador Compcert C y L4.verified:

http://compcert.inria.fr/compcer …
http://www.ertos.nicta.com.au/re …

Escribir software libre de errores es teóricamente posible. Sin embargo, casi todos los proyectos de software evolucionan y crecen continuamente. Dada esta rápida tasa de cambio, es difícil tomarse el tiempo necesario para crear algo que esté completamente libre de errores. Cuanto más complejo se vuelva su software, más difícil será encontrar todos los casos de esquina.

Los proyectos de código abierto a gran escala adoptan el enfoque de “con suficiente atención, todos los errores son superficiales”. No solo es importante tener a alguien que genere escenarios de falla, necesita un gran grupo de personas inteligentes que realicen revisiones constantes del código. Este enfoque es menos racional para el software comercial de código cerrado, por lo que, en cambio, tiene desarrolladores que incorporan pruebas unitarias en su código y utilizan análisis de código y herramientas de depuración en tiempo de ejecución para detectar errores. Además, generalmente hay un equipo de control de calidad con personal que crea y ejecuta planes de prueba que intentan cubrir tantos escenarios de falla como sea posible.

En cuanto a la contratación de una empresa subcontratada para realizar este proceso de control de calidad … Sin acceso directo al código fuente, la familiaridad con los objetivos del proyecto y un gran personal de trabajadores altamente técnicos dedicados, dicha empresa no sería muy eficaz. Dado el alto valor que las compañías otorgan a su código fuente, es extremadamente improbable que una compañía lo entregue a un tercero desconocido para que realmente realice el proceso de control de calidad.

No tengo dudas de que es posible , pero tengo muchas dudas de que la erradicación completa de los errores será económicamente razonable durante mi vida.

Hay algunos campos en los que tiene sentido realizar las inversiones adicionales necesarias para que el software esté realmente libre de errores. En general, estos son campos en los que los errores provocan lesiones o la muerte de personas, como equipos médicos, aviónica, etc. Y hay campos en los que los errores terminan costando mucho dinero, por ejemplo, la reciente pérdida de negociación algorítmica de $ 440M de Knight Capital, y en esos campos tiene sentido mantener la calidad del software lo más alta posible.

Pero para la mayoría de las industrias, la inversión adicional que se requeriría para eliminar hasta el último error simplemente no vale la pena. Esos dólares adicionales se gastarían mejor en otras áreas.

Esta respuesta a la pregunta “¿Qué es el conocimiento común en su lugar de trabajo que sería alucinante para el resto de nosotros” ayudará a explicar por qué eso es:

Respuesta anónima a ¿Qué es algo que es de conocimiento común en su lugar de trabajo, pero que sería alucinante para el resto de nosotros?

Quizás en algún momento en el futuro desarrollemos formas muy económicas de corregir errores sin introducir nuevos errores, pero eso ni siquiera está en el horizonte en este momento. Y hasta que eso suceda, o hasta que los usuarios comiencen a exigir software de mayor calidad (y al decir “exigir” me refiero a “negarse a comprar cualquier cosa menos”), creo que los niveles de calidad que ve hoy se quedarán con nosotros.

PS Knight podría no ser realmente un buen ejemplo. Se ha informado que su pérdida se debió a un error administrativo, no a errores de software. Aparentemente, conectaron por error un sistema de simulación comercial al mercado real. El sistema de simulación era solo una herramienta para probar su software comercial, nunca tuvo la intención de ponerse en funcionamiento.

Hay lenguajes diseñados desde cero de una manera que asegura que el programa haga exactamente lo que usted quiere que haga. En cierto sentido, todos los programas lo hacen, pero en estos idiomas se especifican las restricciones que el programa debe cumplir en un lenguaje que es menos propenso a errores. Por ejemplo, un lenguaje como C que requiere que el programador especifique de manera bastante críptica qué pasos debe realizar la computadora en cierto sentido siempre funciona exactamente como fue escrito, pero aún consideramos algunos casos como errores, porque escribimos no exactamente lo que queríamos a. Por lo tanto, es posible que desee agregar algunas afirmaciones, condiciones previas, condiciones posteriores y usar un comprobador de teoremas para demostrar que un programa C hace lo que usted menciona. Sin embargo, esto requiere que pueda escribir fórmulas sin errores, demostradores de teoremas sin errores, etc. En otras palabras, cambia el lugar donde ocurren errores del código a la especificación. Por supuesto, le da al menos una prueba de fallas, una segunda oportunidad para detectar un error, pero aún así puede simplemente tener una mala especificación (según mi experiencia, es más frecuente que olvidemos algún caso especial en una especificación, que la especificación implementado incorrectamente).

Sin embargo, hay idiomas en los que escribe solo la especificación y el algoritmo se deduce automáticamente de ella. Por ejemplo Prolog. Pero realmente no creo que esto resuelva el problema, ya que el programa Prolog complejo todavía está sujeto a errores, lo que genera algunas “especificaciones de especificación”.

Creo que lo que realmente estoy tratando de decir es que creo en los programas que hacen exactamente lo que pediste, pero realmente no creo en que preguntes exactamente lo que realmente quieres. Considere un buen problema de juguetes para formular un deseo en general: http://lesswrong.com/lw/ld/the_h …

Trabajé en un producto que requería una “calificación de calidad del 85%” por parte del cliente, de lo contrario no podríamos seguir siendo proveedores. Desarrollamos un método para eliminar TODOS los errores visibles / detectables antes de lanzar cualquier software. A tiempo. Esta creencia y esta necesidad solo hicieron que el código estuviera prácticamente libre de errores.

Uno de los mejores ingenieros del equipo fue a otra empresa. Creían que los errores no podían ser erradicados. Tenían miles de errores en los libros trasladados de publicación en publicación. Establecieron una barra para un número “aceptable” de errores (en realidad, la tasa de resolución de errores), luego hicieron un lanzamiento. Estaba estupefacto y nunca pudo convencer a esta compañía multimillonaria de lo contrario.

El 90% del problema es la pereza. Tuvimos “días de erradicación de errores” donde la mitad de los problemas principales se resolverían. Algunos de estos ponen las cosas lo suficientemente bajo control para que todos puedan ver la sabiduría y creer que es posible.

Existe el argumento de que un error es solo un error si el código no cumple con la especificación. Francamente, si soy el cliente de mi propio código y algo no me agrada, es un error. Tenía un jefe de departamento que estaba harto de errores como este … así que reemplazó todos nuestros teléfonos de escritorio con los teléfonos de escritorio que estábamos desarrollando (en los Laboratorios Bell) … lo llamó “comer su propia comida para perros” … fue increíble lo rápido que eran los insectos. Los envíos que se enviaron durante meses se resolvieron después de que las personas tuvieran que vivir con su propia basura.

Se trata de costos y requisitos. En mi última compañía, nuestro software de base de datos incrustado se utilizó en muchos entornos en los que teníamos que pasar los criterios de prueba “críticos para la vida”; se utilizó en sistemas automotrices, algunos dispositivos médicos, algunos equipos de redes de misión crítica y algunos sistemas espaciales, entre otros usos de dispositivos dedicados. Nuestro software no estaba “libre de errores”, pero tenía que pasar casos de uso específicos donde no había errores conocidos encontrados por casos de uso particulares.

Para apoyar esto, necesitábamos hacer lo siguiente:

1. Teníamos una infraestructura de prueba gigantesca con varias decenas de miles de pruebas que se ejecutaban de extremo a extremo cada vez que un ingeniero registraba cualquier código. Agregamos nuevas pruebas diariamente.
2. Cada prueba no solo tuvo que ejecutarse correctamente, sino que también tuvo que pasar la detección de pérdida de memoria y corrupción de memoria con cero errores.
3. No se nos permitía usar ningún software de terceros con excepciones muy específicas, que tenían que estar en una lista pública y documentarse con “defensas” completas de por qué teníamos que usar este software. (La mayoría de las llamadas de terceros eran necesarias para E / S en dispositivos específicos). Casi toda la biblioteca de tiempo de ejecución C no estaba permitida.
4. Compilamos nuestro software con todos los posibles errores y advertencias habilitados.
5. No intentamos manejar demasiado los errores, pensando que era mejor fallar que intentar escribir un código de recuperación imposible de probar para cada excepción. Manejamos errores de memoria y errores generados por código de terceros, así como algunos errores de estado, pero eso fue todo. (Ser una base de datos relacional con recuperación y un motor de almacenamiento simple compatible con ACID ayudó con esto).
6. Las aplicaciones del cliente que utilizaron nuestro software tuvieron que ser rigurosamente probadas por el cliente, incluidos todos los formularios de consulta posibles.

Sería difícil generalizar este enfoque a más software de “propósito general”; incluso si su propio código es de alguna manera perfecto, habrá errores e inconsistencias en las bibliotecas / frameworks / etc subyacentes. Además, este nivel de prueba es bastante costoso, aunque necesario y útil para algunos tipos de software.

Hay algunas aplicaciones donde la eliminación de errores es crítica. Cosas como el control de la central nuclear, el lanzamiento de cohetes. Hace un tiempo leí un artículo sobre la estructura de desarrollo completamente diferente utilizada para estas aplicaciones. Muy basado en la especificación, muchas pruebas formales de corrección y un lenguaje especializado. Un punto que recuerdo sobre el artículo fue que la mayoría de las personas que trabajaban en él eran mujeres.

Por ejemplo, los desarrolladores de programas de centrales nucleares tienen un documento de licencia muy estricto (página en onr.org.uk) que especifica cada aspecto de cómo se desarrolla el software.

He sido desarrollador y gerente de software por más de 30 años. Ahora tengo mi propia compañía de software: Flint Hills Group. Sé por experiencia que el software libre de errores es posible PERO hay un gran costo en tiempo y dinero para lograr este objetivo. La mayoría de las empresas no están dispuestas a pagar el costo a tiempo o los fondos del proyecto para lograr la perfección. A menudo, este objetivo de perfección no tiene sentido para la mayoría de las empresas, pero muchos CEO y líderes empresariales no lo entienden. Apple, Microsoft, Google junto con todas las grandes compañías tecnológicas envían sus productos con cientos de errores cada año. ¡Vea cuán exitosos son y cuántas personas usan sus servicios! No envían soluciones perfectas, pero entienden que no tiene sentido hacerlo.

Mi primer trabajo después de obtener mi título en informática fue en Boeing escribiendo aviónica de bombarderos B-52 que entregaba armas nucleares. Si alguna vez hubo una razón para escribir código perfecto, esta fue la razón. Pasamos literalmente años escribiendo y probando estas soluciones antes de ponerlas en combate. El costo de construir y probar soluciones fue de cientos de millones de dólares cuando se suman los costos que abarcan Boeing y la Fuerza Aérea de los EE. UU. La mayoría de las empresas no pueden permitirse hacer esto, ¡pero quién quiere encontrar un error mientras arroja una bomba nuclear! Por extraño que parezca, todavía encontramos errores en el software de aviónica 1, 2, incluso 3 años después de que se entregó a la Fuerza Aérea y se utilizó en combate.

Lo que les decimos a los clientes del Grupo Flint Hills es que creamos soluciones sólidas en un 80-85% que satisfacen sus requisitos y resuelven sus problemas comerciales de manera efectiva. Nos asociamos con nuestros clientes en nuestras pruebas para que realicen pruebas de aceptación del cliente después de nuestro módulo y las pruebas de integración. Les decimos que el costo del código sólido del 90% es 2 veces nuestro precio normal y el código sólido del 100% es 8-10 veces nuestro precio normal. Nuestros clientes aprecian nuestra sinceridad y asociación en estos proyectos de software personalizados. Hasta ahora, nadie ha buscado la opción de perfección a un costo 10 veces mayor.

No dude en comunicarse conmigo o visite nuestro sitio web para obtener más información sobre el costo de crear software personalizado de calidad que resuelva los problemas comerciales sin tener que ir al banco – Todos los desarrolladores de software personalizados con sede en los EE. Flint Hills Group

En principal, sí. En la práctica, mucho menos probable.

Como dijo Vasanth, en un caso trivial, puede escribir fácilmente software libre de defectos. En sistemas no triviales, es mucho más probable que se introduzcan defectos en alguna etapa del proceso, y también es menos probable que se identifiquen.

Otro problema con el concepto de “software libre de defectos” es definir claramente qué quiere decir con “defecto”.

¿Se refiere solo a errores de codificación que causan salidas incorrectas o comportamiento inestable? ¿Se refiere a decisiones arquitectónicas que afectan la escalabilidad o la solidez? ¿Qué tal fallas de su código para compensar las debilidades del sistema operativo subyacente?

Volviendo más atrás en el proceso, ¿se refiere a defectos que surgen de las limitaciones del proceso de recopilación de requisitos, lo que lleva a que se escriba el software “incorrecto”?

¿Qué pasa con los problemas de usabilidad debido a la incapacidad de los desarrolladores para pensar como un usuario?

Hay tantas fuentes para identificar defectos en el producto final que es improbable que todos sean detectados.

Sin embargo, supongamos que tenemos una visión claramente articulada de lo que constituye un defecto. Todo desarrollo de software no trivial implica un equilibrio entre el desarrollo de costos, el tiempo de desarrollo, cuándo debe hacerse y cuán crítico es el software (¿qué tan bueno es lo suficientemente bueno? ¿Cuáles son las implicaciones de las fallas?).

Por lo general, hay dos formas de acercarse al software sin defectos:

1. Invierta en procesos que reducen la probabilidad de que se introduzcan defectos
2. Invierta en procesos de prueba que reduzcan la probabilidad de que los defectos no se descubran antes del lanzamiento.

Ambos cuestan tiempo y dinero. Los métodos formales son caros. Los procesos pesados ​​son caros. Los programas de prueba pueden agregar tiempo y costo significativos a un proyecto (y encontrar defectos al final del proceso los hace costosos de reparar).

¿Cuánto tiempo y dinero inviertes en el proceso? ¿Cuánto cuesta la prueba? Ahí es donde entran en juego las compensaciones y la toma de decisiones. Si está creando un software del que dependen las vidas de las personas, entonces tiene sentido realizar grandes inversiones en procesos y pruebas, ya que las implicaciones de la falla son graves.

Si está escribiendo un sitio web corporativo, entonces tal vez una menor inversión tenga sentido ya que el impacto de un defecto menor no es muy alto.

Entonces, la respuesta corta es que sí, puede acercarse mucho al software libre de defectos, pero le costará y puede que no valga la pena el costo en todas las situaciones.

Yo diría, teóricamente posible. Si tiene una especificación claramente definida y algún software, existen métodos formales para verificar si su software cumple con las especificaciones / propiedades, lo que se denomina verificación de modelo. O puede ingresar sus especificaciones en un “sintetizador” y dejar que genere un software utilizando algunos métodos matemáticos que satisfagan sus requisitos.

Sin embargo, para el software real, actualmente no es práctico verificarlo o sintetizarlo. Y para reducir la posibilidad de cometer errores, se adopta ampliamente el enfoque de diseño basado en módulos, así como la reutilización del diseño.

La verificación formal se puede usar para asegurar que todas las entradas posibles a una pieza de software produzcan la salida esperada, pero esto no es realmente posible para un software complejo que realmente hace algo útil.

Creo que lo más cerca que alguien ha estado de escribir software libre de errores es en la NASA. Todo su proceso de desarrollo fue diseñado para encontrar todos los errores. Recomiendo leer el artículo de 1996 ‘Escriben las cosas correctas’ de Charles Fishman si está interesado en el proceso que utilizaron.

Sí, mediante el uso de la verificación formal.

Esta es una pregunta interesante, pero el hecho es que no es una pregunta importante , la mayoría de las veces.

Vives con una mujer (un hombre) que no es perfecta. Tu casa no es perfecta. Tus hijos no son perfectos. Tu hígado no lo es y tu mamá y tu papá son geniales pero, bueno, no son perfectos en absoluto. Nada es perfecto (excepto, a veces, las matemáticas).

Podemos vivir felices en este mundo porque podemos adaptarnos fácilmente a errores y comportamientos inesperados.

Con respecto al software, a todos nos encantaría tener algo que funcione todo el tiempo como se esperaba. Esto es posible, pero el costo para lograr esta perfección puede ser, sería, astronómico. Todos preferimos una copia de un Windows con errores de 50 euros a un sistema operativo perfecto de 10000000 euros. Y preferimos un Instragram incompleto ahora a un Instagram perfecto en 13 años a partir de ahora.

La perfección está fuera de este mundo. Los proyectos de software que intentaron ser perfectos fracasaron miserablemente. Parte porque la perfección tiene un costo enorme y parte porque probablemente no tendríamos la misma definición de perfección.

El software libre de errores no debería ser tu mantra. Software útil debería ser. Solo dígale a la gente que mejorará con el tiempo.

Salud.

Sí, dependiendo de su alcance.

Cuanto más claramente pueda especificar un problema, más fácil será escribir una solución “perfecta”.

¿Es posible escribir una API de lista libre de errores? Seguro. La gente lo hace todo el tiempo y muchas bibliotecas estándar de idiomas tienen bibliotecas perfectas y sin fallas para estructuras de datos básicas y otras tareas limitadas estándar.

¿Es posible escribir una base de datos distribuida libre de errores? Mucho, mucho más difícil.

Cuanto más grandes y complicados sean los requisitos, más probable es que las fallas se hayan colado en la base del código en alguna parte.

Esta es una de las razones por las que la componibilidad es tan importante en la programación funcional. Cuando su código es simplemente una composición declarativa de unidades “perfectas”, tiene muchas más posibilidades de que el resultado esté libre de fallas (los problemas aquí surgen como errores de integración, donde su composición declarativa no significa lo que el programador inicialmente pensó que hizo) .

¡NO hay software sin errores !

Ningún programa es absolutamente perfecto. Los programas y los errores son simbiosis perfectas, son como los humanos y las bacterias, como las abejas y las orquídeas. Los programas son los hábitats naturales de los errores de software, mientras que los errores son a menudo el impulso para mejoras, mejoras e innovación. La perfección es solo una ilusión , simplemente no existe y las TI no son una excepción.

El error de software es una criatura maravillosa, no dude en descubrir por qué:

¡Error de software, una criatura maravillosa! – Paralelismo

Software sin errores: un mito moderno que debe tratarse correctamente. Lo mejor es reaccionar rápidamente a los errores que aparecen. Después de que QA resuelva todos los escenarios de falla que puedan, siempre habrá algo que aparecerá durante un tiempo determinado. Eche un vistazo a las aplicaciones que tiene en su dispositivo móvil: hay actualizaciones frecuentes, y tal vez la mitad de ellas se refiere a la corrección de errores, que se indica en ‘Novedades’. Incluso las aplicaciones más populares y más longevas (por ejemplo, Twitter, Dropbox, Gmail, etc.), todas pasan por actualizaciones para durar más tiempo y permanecer frescas, pulidas y relevantes para las nuevas oleadas de usuarios.

Sí, es posible. Es posible que no esté 100% libre de errores, sin embargo, es posible tener un código muy estable, extensible y altamente mantenible dentro de la línea de tiempo del proyecto. Incluso si se encuentran pocos errores de condición remota / límite durante la fase de prueba, si puede acomodar la solución en ningún momento, sin ningún cambio de diseño y sin introducir nuevos errores, se considera un gran éxito.

Proporcionaré dos instancias donde entregué código libre de errores.

Instancia 1: en el 2004 escribí una pieza de software para un operador australiano de telecomunicaciones. Luego seguí adelante y no trabajé para ese cliente. En 2012 visité las instalaciones de ese cliente para otro proyecto. Mientras caminaba por el pasillo, me encontré con mi entonces cliente, a quien en realidad acepté la entrega del software en el que trabajé en 2004. Durante la conversación, mencionó que el software todavía estaba en producción, funcionaba en su mayor parte sin problemas. Ha habido pocas mejoras desde 2004, pero ninguna versión de mantenimiento de errores. Ahora esta fue una gran declaración. De hecho, demuestra que es posible tener software libre de errores.

Instancia 2: en 2014 tuve la oportunidad de desempeñar el papel de desarrollador. Diseñé, diseñé y codifiqué un servidor API. Investigué mucho mientras codificaba. Intenté usar nuevos patrones, estructuras de datos, estilo de codificación. Traté de evitar el bloqueo if / else, incrustado la lógica dentro de las estructuras de datos. Utilicé llamadas a métodos dinámicos, pasé todas las llamadas de API a través de un conjunto de comprobaciones antes de tomar medidas. Formé una respuesta API a través de un bloque estándar. Escribí nuevas estructuras de datos y patrones para satisfacer mis requisitos. Después de todo el trabajo inteligente, se entregó dentro del tiempo estimado. Pasó por pruebas internas, luego las pruebas de integración finalmente llegaron a la mano de los clientes. Nadie encontró ningún problema. Luego recibí una llamada del probador de integración. Era un miembro senior del equipo. Me dijo que trató de romper varias condiciones de frontera, pasó una semana, pero no tuvo éxito. Reforzó mi creencia de que es posible tener un código libre de errores.

Si sigue algunos principios básicos como: Código estructurado, fácil de leer y comprender, evite bloques complejos si no, use funciones de biblioteca, escriba el menor código posible, use patrones y estructuras de datos, no intente reinventar la rueda y finalmente Verifique la integridad de los datos de entrada, la condición de límite, la verificación del rango de valores antes de realizar cualquier acción, la verificación del estado, etc. Intente poner todo esto en su marco para que nadie lo pierda y cada llamada a la función / llamada API pase por estas verificaciones. Estás listo. Les deseo todo lo mejor.

Desarrollo de software libre Happy Bug …

Aquí hay una respuesta que aún no se ha dado: no con la tecnología actual, porque el hardware es defectuoso. Su computadora promedio tiene millones de puertas que se disparan constantemente; No todos ellos funcionan. Por lo tanto, hay copias de seguridad y copias de seguridad de copias de seguridad, etc. de esas puertas. Lo que estoy tratando de decir es fundamentalmente a nivel de ensamblaje / puerta / hardware, hay una falla que no se ha resuelto. No es posible construir una aplicación de software libre de errores en un sistema (léase: perfecto) que sea estático (no cambia) y no pueda repararse solo si tiene problemas para comenzar. Quizás con la biocomputación en el futuro, veremos CPU y sistemas de hardware autocorregibles; Si eso sucede, prepárese para Terminator.