Mi respuesta será desde la perspectiva de los negocios del mundo real y los desafíos que enfrenta cada equipo de desarrollo. Lo que veo en esta pregunta y muchas de las respuestas es realmente sobre el control de defectos.
El código puede estar libre de errores. Tome cualquiera de los ejemplos de código "Hello World" para cualquier lenguaje de programación y ejecútelo en la plataforma a la que está destinado y funcionará de manera consistente y producirá los resultados deseados. Allí termina cualquier teoría sobre la imposibilidad de que el código esté libre de errores.
Los posibles errores aparecen a medida que la lógica se vuelve más compleja. El simple ejemplo de Hello World no tiene lógica y hace lo mismo estático cada vez. Tan pronto como agregue un comportamiento dinámico impulsado por la lógica, es lo que introduce la complejidad que conduce a los errores. La lógica en sí misma puede ser defectuosa, o los datos que se ingresan a la lógica pueden variar de una manera que la lógica no maneja.
Una aplicación moderna también depende de las bibliotecas en tiempo de ejecución, CLR, middleware, bases de datos, etc. que, si bien ahorran tiempo de desarrollo en general, también son capas donde pueden existir errores dentro de esas capas y pasar desapercibidas a través del desarrollo y las pruebas UAT y en la producción.
Por último, la cadena de aplicaciones / sistemas de los que la aplicación consume datos que alimentan su lógica son todas fuentes de posibles errores, ya sea dentro de su lógica, o dentro de las pilas de software que se encuentran en la parte superior, o los sistemas ascendentes que consume datos.
Los desarrolladores no tienen el control del 100% de cada pieza móvil que admite la lógica de su aplicación. En realidad, no tenemos mucho control. Es por eso que las pruebas unitarias son importantes, y la configuración y la gestión de cambios son procesos importantes que no debemos ignorar o ser flojos / descuidados.
Además, los acuerdos documentados entre su aplicación que consumen datos de una fuente más allá de su control, que define el formato específico y las especificaciones para los datos transferidos, así como cualquier límite o restricción que su sistema asume que el sistema fuente es responsable de garantizar que la salida esté dentro esos límites
En la aplicación del mundo real de la ingeniería de software, no podrá hacerlo volar explicando a la empresa por qué, en teoría, las aplicaciones no pueden estar libres de errores. Las discusiones de esta naturaleza entre la tecnología y el negocio nunca sucederán, excepto después de un mal funcionamiento tecnológico que afectó la capacidad del negocio para ganar dinero, evitar perder dinero y / o mantener con vida a las personas. La respuesta a "cómo puede suceder esto" no puede ser "déjenme explicar esta teoría para que entiendan".
En términos de cálculos masivos que teóricamente podrían llevar una eternidad realizar el cálculo y obtener un resultado, una aplicación que no puede finalizar y regresar con un resultado, eso es un error. Si la naturaleza del cómputo es tal que consume mucho tiempo y es intensivo en cómputo, usted toma esa solicitud y le brinda retroalimentación al usuario sobre cómo / cuándo puede recuperar el resultado, y comienza los hilos paralelos para obtenerlo. Si esto tiene que suceder más rápido de lo que se puede hacer en un servidor, y es un negocio lo suficientemente importante, entonces puede escalarlo en tantos sistemas como sea necesario. Esta es la razón por la cual la nube es muy atractiva, y la capacidad de activar nodos para asumir el trabajo y reducirlos cuando haya terminado.
Si existe la posibilidad de obtener una solicitud que ninguna cantidad de potencia de cómputo puede completar, no debe pasar el tiempo corriendo hasta el infinito con un proceso de negocios esperando la respuesta a lo que la empresa cree que es un problema finito.
print "Hello, World!"... ¿puedes ser un poco más claro?