¿Por qué el software no es tan confiable como un automóvil? [cerrado]

Un usuario me hizo esta pregunta. Sabemos que los autos se descomponen, pero eso se debe a algo físico (¡a menos que el software esté involucrado!).

Traté de responder que el software es una industria mucho más joven, pero el usuario respondió "¿la industria del automóvil no se volvió mucho más estable y confiable con menos gente?".

También traté de responder que el software es más complejo, pero el usuario respondió que hay miles de piezas que componen un automóvil. Las personas que diseñan y fabrican automóviles generalmente conocen muy bien sus componentes, pero todos terminan trabajando juntos como resultado final.

Entonces, ¿por qué el software no es tan confiable como un automóvil?

La premisa de su pregunta es simplemente incorrecta: el software no es "menos confiable" que un automóvil. Existen miles y miles de millones de dispositivos que ejecutan software integrado las 24 horas, los 7 días de la semana, sin problemas. Diablos, algunos de ellos están en automóviles y controlan / monitorean el motor. Entonces, ¿cómo puede el software ser menos confiable que un automóvil, si los automóviles mismos dependen del software?

Diseño software y piezas mecánicas.

Es la complejidad.

Porque hay millones de "partes" en el software moderno.

Las partes de software son muy complicadas y tienen mucho ESTADO. Una parte mecánica no móvil no tiene estado.

Una parte móvil mecánica tiene su posición (una variable).

Un programa que se ejecuta y usa 1Mb de RAM tiene un millón de bytes de estado. Eso es mucho más estado que cualquier sistema mecánico normal.

Habrá una combinación de estados que nunca se evaluarán porque suceden muy raramente. En un sistema mecánico (como un automóvil) es fácil verificar que las partes mecánicas no se golpeen entre sí durante la operación. El software CAD mecánico que uso en el trabajo lo hace automáticamente.

Si construyeras máquinas a partir de partes invisibles, no tocables, y tuvieras millones de partes móviles que simplemente se echaran de menos, sería como un simple programa.

Incluso "hello world" se ejecuta en un sistema operativo. Los viejos sistemas operativos de 8 bits y miniordenadores eran bastante confiables porque eran simples.

Cosas como archivos DLL y bibliotecas compartidas se reemplazan como parte de actualizaciones de virus o instalaciones de software y luego el programa de interés no funciona. Un poco como cambiar la llanta de tu auto por una de bicicleta. Algunos de los estados de borde de la función de la biblioteca interfieren (no actúes como el programa espera)

Los programas escritos en lenguajes como Java que no permiten muchas interacciones no diseñadas entre objetos (reutilización de puntero, desbordamientos de límites de matriz) son generalmente bastante confiables una vez que los hace funcionar.
Cuando utiliza sistemas operativos con bibliotecas estáticas, una vez que un programa funciona, sigue funcionando (pero aún tendrá muchas condiciones de borde, en función de su tamaño de estado).

Dave Parnas escribe sobre cómo obtener confiabilidad en el software al reducir el estado del programa. Los chicos de programación funcional estricta están haciendo lo mismo al forzar una sola asignación estática.

Es una cuestión de elección del consumidor.

Si los consumidores exigieran que el software fuera tan confiable como mi Honda Civic (a diferencia de mi viejo Ford Maverick), lo sería. Algunas organizaciones exigen software tan confiable, y lo obtienen, generalmente para software integrado, a veces para cosas críticas para la seguridad, como misiones espaciales y control de tráfico aéreo. El software aún no es perfecto, pero tampoco lo son los automóviles.

Sin embargo, los clientes exigen otras cualidades en su software y, en su mayoría, no están dispuestos a pagar por un software que posiblemente sea menos funcional, ciertamente más caro y se envíe más tarde solo porque es más confiable.

Hay muchos miles de piezas que componen un automóvil.

Si tan solo una computadora (y el software asociado) fuera así de simple.

¿La computadora tiene qué gigabyte de memoria? ¿Miles de millones de chanclas? ¿Un terabyte de disco? ¿Trillones de partes "móviles"?

El software puede tener 10s de miles o 100s de miles de líneas individuales de código en ejecución. Además de eso (o más) en pruebas unitarias y herramientas.

No. El argumento de "los autos también son complejos" es una tontería. El software es mucho, mucho, mucho más complejo que un automóvil.

Los principios que hacen que los motores de combustión funcionen, y todos los componentes que componen un automóvil no han cambiado mucho en el siglo pasado. Claro que ha habido mejoras evolutivas y autos híbridos, pero los componentes básicos son los mismos. Tienes un motor, un tren de transmisión, etc. Incluso los autos conceptuales y tu súper caro y extremadamente rápido Bugatti Veyron están construidos con la misma estructura básica. En resumen, diseñar un automóvil es un problema bien conocido .

Compare eso con el desarrollo de software.

• Los clientes no saben lo que quieren cuando comienzan. Comienzan a hablar de un jet de lujo, pero cuando se dan cuenta de los costos, quieren que lo construyas por el costo de un scooter de pie.
• El diseño del automóvil lleva años para pasar de la idea al automóvil conceptual, y más años para llegar desde allí a la fabricación. ¿Cuándo fue la última vez que tuvo ese lujo con el software?
• Las piezas del automóvil son piezas de metal fundido, pero los componentes de software pueden cambiar de forma e interfaz a menudo.
• El proceso de fabricación es completamente diferente. Con los automóviles, las piezas se fabrican en grandes cantidades y las mismas piezas se utilizan en diferentes vehículos. Con el software, casi todo está hecho a mano porque, de lo contrario, las cosas simplemente no encajan.

En resumen, hay una serie de razones por las cuales un automóvil sería percibido como "más confiable" que el software. Se me ocurrió una pareja.

Los autos son confiables. Así es la mayoría del software.

Pero ... los autos personalizados y el software personalizado, ambos tienen sus problemas.

Cualquier entusiasta de los autos reales, que tiene su muscle car modificado de 1970, retoques y ajustes, y tiene fallas, y todo tipo de problemas estúpidos que no habría tenido si lo hubiera dejado original. Pero ... entonces no tendría el sobrealimentador ...

Debido a que el automóvil que conduce se ha fabricado muchas veces, el proceso de construcción es tan refinado que el mismo automóvil se puede fabricar en una línea de producción una y otra vez.

Si se tratara de un automóvil complejo de vanguardia, único en su tipo, construido desde cero una vez, no sería tan confiable, por ejemplo, mire cuánto más alto es el índice de fallas en los automóviles de carreras de fórmula 1. Es común que uno o dos se descompongan por carrera.

El nuevo software es siempre una vez. Lo que el código de los programadores nunca ha sido codificado por ellos antes. Obtener una calidad realmente alta en este escenario implica un costo prohibitivo para la mayoría de los productos. Cada nuevo software no trivial es efectivamente un prototipo.

Además, esta es una de las principales razones por las que la aplicación de técnicas de ingeniería tradicionales a la ingeniería de software es un desastre.

1. Los fabricantes de automóviles obtienen la especificación completa antes de producir el producto "final".
2. Los usuarios de automóviles no tienden a hacer cosas estúpidas que los diseñadores no esperaban.
3. Los automóviles solo se "actualizan" una vez al año (normalmente), mientras que se espera que la mayoría del software se actualice muchas veces al año.

Podría continuar, pero mi navegador parece que está a punto de fallar ...

En realidad, hay una razón muy simple.

El software que hace dinero es un software que obtiene participación de mercado. La mayoría de las veces, la compañía que primero trae una pieza de software al mercado será la que obtenga la mayor parte de la participación de mercado, incluso si su software no es el mejor producto en su mercado particular.

En consecuencia, el objetivo es lograr que el software se publique más pronto e imperfecto, en lugar de más tarde y perfecto.

Me gusta la mayoría de las respuestas hasta ahora. Aquí está mi giro.

El costo por falla es más severo para los automóviles que el software

La falla del automóvil podría costarle la vida. Incluso una falla del vehículo que no ponga en peligro la vida representa un inconveniente muy visible para el usuario. La falla del software solo significa que un poco de savia pobre en el soporte de producción tendrá que trabajar horas extras. Y si esa persona es un empleado exento de tiempo completo, entonces Dios mío, no es tan caro en absoluto. De hecho, la mala calidad y la mala gestión se ven recompensadas porque las horas extras gratuitas en realidad reducen el costo laboral por hora.

Por supuesto, esto depende del tipo de software que se esté utilizando (el software que alimenta sistemas de armas, aviónica o sistemas médicos también podría tener un efecto en la vida), pero un automóvil cuesta una gran cantidad de dinero y se usa con suficiente regularidad que carece de fiabilidad. bastante tangible y doloroso Las fallas de software a menudo tienen soluciones alternativas.

Otro pensamiento: los automóviles parecen confiables, pero tienen costos de mantenimiento definitivos que están en curso, incluso si el automóvil funciona bien, y culturalmente, esto es aceptado e incluso un gasto orgulloso por las personas que se preocupan por sus vehículos. El software, por otro lado, a menudo ya está roto cuando se instala, y a menudo tiene que cambiar con el tiempo, pero culturalmente, nadie quiere pagar por el mantenimiento.

Bueno, los autos eran poco confiables durante la mayor parte de su historia, y definitivamente hay una curva de aprendizaje. Los automóviles se han producido a gran escala durante aproximadamente 60 años, mientras que el software solo se ha producido a gran escala durante aproximadamente 20-25. Por gran escala, básicamente me refiero a lo suficientemente grande como para que las masas lo compren / usen y hay un gran incentivo para descubrir cómo perfeccionar el procedimiento para crearlo.

Me gusta pensar en el automóvil como una aplicación. Mientras que el sistema operativo es el camino en el que se ejecuta la aplicación.

La interfaz entre carretera y automóvil está bien definida. Bien probado y se verifica ampliamente la compatibilidad con versiones anteriores (lo cual es fácil ya que la interfaz es simple). Pero aun así tiene algunos problemas de compatibilidad con versiones anteriores. Los automóviles del tipo "Farrie" tienen dificultades para circular por carreteras del tipo "carreteras de barro".

Aun así, su sistema operativo al igual que las carreteras necesita un mantenimiento constante. Puentes de mercancías. Los autos se ponen cadenas de nieve y rompen las carreteras como si la aplicación corrompiera y dañara los discos y archivos utilizados por el sistema operativo.

Las aplicaciones se escribirán en un sistema operativo. Pero, en general, deben ejecutar diferentes versiones del sistema operativo (diferentes tipos de carreteras). Por lo tanto, su aplicación optimizada para la cena puede funcionar sin problemas y sin problemas siempre que se ejecute en el sistema operativo correcto (autopistas), mientras que otro código de propósito general (más simple) funcionará bien en todos los tipos de carreteras.

La interfaz entre la aplicación y el sistema operativo está definida pero es extremadamente compleja y siempre fluctúa ligeramente. Especialmente porque permitimos que el usuario modifique su propio sistema operativo con extensiones. Si el gobierno permitiera a los usuarios modificar las carreteras, habría muchos más accidentes.

Cuando comienza a limitar la capacidad del usuario para modificar el sistema operativo, la confiabilidad de las aplicaciones puede volverse casi sólida. Mira todos esos dispositivos integrados. No permitimos que los usuarios se acerquen a su sistema operativo y funcionen bien y continuamente 24/7 sin interrupción.

Entonces diría que no es ese software poco confiable. Es más como decir que los usuarios están cavando agujeros en la carretera para las aplicaciones. Oye, tu aplicación acaba de estrellarse en el agujero que cavé el año pasado y me olvidé .

Primero, su usuario necesita saber que hay un software tan confiable en este mundo que ni siquiera sabe que existe. ¿Alguna vez has visto un accidente de TV? Yo tampoco.

Creo que la razón principal es que el software es irrelevante. Ser irrelevante significa que los que no son desarrolladores no ven el progreso. Por ejemplo, si estuviera haciendo un automóvil, podría verme ensamblar las diferentes partes y se vería cada vez más como un automóvil; sin embargo, si me miras programando, tal vez pasaré horas maldiciendo en una pantalla negra con texto verde haciendo patrones extraños y luego, de repente, cuando el patrón cambie solo un poco, me sobreexcitaré.

Debido a eso, las personas normales no se dan cuenta de la complejidad del software. Cuando ven una ventana, piensan que ven el programa como un todo, lo cual está muy mal.

Además, el software se personaliza mucho, mucho más a menudo que los automóviles. Cuando personaliza un automóvil, no irá en contra de su diseño porque eso sería visiblemente estúpido. Si mi motor está en la parte delantera del automóvil, moverlo hacia atrás probablemente sea un gran desastre. Sin embargo, dado que el software es irrelevante, si el cliente le pide que haga algo completamente en contra del diseño, no obtendrá ninguna indicación (excepto usted, pero no escuchará) que lo que está haciendo es estúpido, y luego ' Me sorprenderá que no funcione como se esperaba.

1. Falta de intercambio de información (los programadores vuelan solos o en grupos pequeños; los diseñadores de automóviles trabajan con equipos interconectados dentro de una gran corporación, y todos comparten su conocimiento; si todos trabajáramos para grandes corporaciones, todos seríamos mejores programadores debido al aprendizaje de otros; también es por eso que cosas como los programas de código abierto y los recursos en línea son muy importantes)
2. Expectativas de los participantes en el campo (está bien si un diseñador de automóviles solo es marginalmente útil durante los primeros 5-10 años, pero si un programador entra en una entrevista y dice que no será de mucha utilidad durante 5-10 años, el la entrevista ha terminado)
3. Falta de pruebas de penetración (debido a la falta de fondos, problemas de legalidad, etc., los fabricantes de automóviles, sin embargo, golpean un automóvil tras otro contra una pared de ladrillos, tienen túneles de viento, tienen requisitos de rendimiento relativamente sencillos, etc.)
4. Transparencia de la información (no sabe cómo funciona la mayoría del software; adivina o hace suposiciones basadas en entrevistas, comunicados de prensa, publicidad, etc .; con los automóviles, sin embargo, la mayoría de las cosas están ahí para que las vea)
5. Encapsulación inherente del conocimiento (el tipo / robot que está soldando el marco no necesita conocer las matemáticas detrás del sistema de control de estabilidad; los programadores deben conocer miles o decenas de miles de cosas desconocidas para la persona promedio, mientras que los diseñadores de automóviles solo necesita saber cientos o miles)
6. Tangibilidad (ayuda cuando puedes verlo)
7. Edad del campo (el diseño del vehículo tiene miles de años; el diseño del vehículo motorizado tiene más de 250 años [máquinas de vapor, etc.])
8. Crítica de los subsistemas (los automóviles seguirán "funcionando" incluso si muchas de sus partes dejan de funcionar: cerraduras eléctricas, ventanas eléctricas, HVAC, limpiaparabrisas, ventanas rotas, tapacubos perdidos, llantas pinchadas [poner una nueva], radio, una luz o dos, entrada remota, etc., cuando algo en una computadora se rompe, a menudo es un escenario SHTF)
9. Interdependencia (cuando una computadora se rompe, no es raro que afecte a cientos o miles de otras computadoras; cuando un auto se rompe, es algo raro que otros autos se vean afectados; si otros autos se ven afectados, casi siempre es solo 1 -3)
10. Culpabilidad general (si una parte de una computadora o una de cada miles se rompe y daña un sistema, la culpa se extiende a toda la computadora, o en el último caso, a toda la red de computadoras; si su automóvil es golpeado por un automóvil con frenos fallidos, o si un automóvil se detiene y no se reinicia en la carretera, solo se culpa a la parte individual del automóvil)
11. Sistemas finitos frente a infinitos (los automóviles solo pueden tener mucho empaquetado, y solo se espera que funcionen en condiciones limitadas, por ejemplo, no conduzca un BMW sobre terreno que solo un vehículo tipo Jeep puede hacer; con computadoras, sin embargo, las posibilidades son infinitas de facto: hay cosas nuevas todo el tiempo, nuevas API, nuevos sistemas operativos, nuevos agujeros de seguridad, iPads, software para teléfonos móviles, nuevo esto, nuevo aquello, etc.)
12. Alcance del conjunto de conocimientos requerido (una persona con un coeficiente intelectual de 130-140 podría aprender casi todo lo que hay que saber sobre automóviles, pero solo podría aprender una fracción de lo que hay que saber sobre computadoras y programación)

La razón simple por la cual toda la lógica es defectuosa:

Los dispositivos mecánicos pueden simplemente reducirse a Entrada / Salida ; aumentar el número de partes para lograr esta operación de E / S no cambia la operación de E / S. Por lo tanto, el sistema puede ser completamente comprendido.

El software por otro lado tiene Entrada -> Proceso -> Salida . Debido a esta naturaleza, el sistema no se puede predecir o comprender completamente.

Donald Rumsfeld lo dijo mejor:

“Hay conocidos conocidos; Hay cosas que sabemos que sabemos. También sabemos que hay incógnitas conocidas; es decir, sabemos que hay algunas cosas que no sabemos. Pero también hay incógnitas desconocidas, las que no sabemos que no sabemos. "- Secretario de Defensa de los Estados Unidos, Donald Rumsfeld

En resumen:

• Un dispositivo mecánico es un sistema que ha conocido, y desconocidos conocidos,
• El software tiene lo anterior pero también incógnitas desconocidas.

Esta es una pregunta estúpida (no de ti, sino de la persona original).

Esto suena como mi padre (un mecánico) que odia las computadoras pero que pasa todo el día en eBay.

Es como preguntar "¿Por qué un árbol es más confiable que una polilla?".

En primer lugar, tengo 30 computadoras (sí, más de 30) y ninguna de ellas ha estado en la tienda. Acabo de gastar $ 1400 en mi automóvil en reparaciones. Vaya a contar el número de talleres de reparación de automóviles vs reparación de computadoras. Una vez más, estúpida analogía.

Los automóviles están hechos de acero, las computadoras de plástico. Los automóviles funcionan en todas las condiciones climáticas, computadoras diseñadas para uso en interiores.

Mi Commodore 64 (26 años) funciona perfectamente y no ha sido reparado. Mis dos vehículos (de menos de 10 años) han tenido una reparación muy extensa. Muéstrame un automóvil con miles y miles de horas de uso que tenga 26 años y que funcione 100% igual que cuando era nuevo de fábrica.

El software se basa en bits: 0 y 1. Los automóviles se basan (principalmente) en partes mecánicas.

Una parte mecánica puede desgastarse o funcionar mal y aún así ser un tipo de trabajo. Sus frenos se desgastan o una válvula tiene fugas, pero el automóvil aún funciona principalmente hasta que pueda repararlo.

El software, en su mayor parte, no tiene una falla gradual. Funciona o se rompe. Dividir por cero no es "casi correcto"; Es solo un error. Cuando intenta guardar en una unidad sin suficiente espacio, no puede apretar con fuerza para forzar todos los datos; simplemente no irá.

No creo que el software sea necesariamente menos confiable que un automóvil, pero cuando el software falla, falla inmediatamente, no gradualmente.

Creo que tengo una analogía mucho mejor. Tome una empresa que construya ambulancias según las especificaciones del cliente. La plataforma base (por ejemplo, un chasis de vehículos recreativos RV totalmente operativos y legales para la calle) requiere modificaciones en varios puntos: marco, sistema de carga, boquilla de llenado, suspensión, etc. Esas modificaciones no solo deben ser legales para la calle sino que deben cumplir con los requisitos jurisdiccionales mientras satisface los deseos del cliente.

Luego, debe construir el propio cuerpo de ambulancia, que también está lleno de requisitos reglamentarios de varias capas del gobierno y otros organismos. Sin dejar de satisfacer el deseo del cliente de un arreglo de asientos o sistema de almacenamiento original. Y no olvide que tiene cientos de clientes diferentes de todo el mundo, todos con diferentes horarios de compras e implementación, ninguno de los cuales dice "Tomaré una docena más como el último" sin enviar también páginas de excepciones que Con frecuencia requieren una reingeniería completa de todo el asunto.

¿Coches? Eso es trivial Comprará lo que está construido y no tendrá un impacto directo en ningún aspecto del diseño. Incluso su elección de color es artificial porque en realidad no puede especificar algo que aún no ha sido diseñado y probado. En cierto sentido, solo hay un "mercado", no un "cliente". Yo diría que el software comercial producido para algunos mercados es generalmente tan confiable como el automóvil que usted recoge en el concesionario local.

Los autos no son tan confiables como crees. Es solo que las fallas pueden permanecer ocultas durante mucho tiempo (o ignorarse) sin hacer que todo falle. ¿Su automóvil tiene fugas de aceite y / o refrigerante? ¿No? ¿Estás seguro? Probablemente esté equivocado ... Probablemente solo esté goteando una cantidad muy pequeña en algún lugar que aún no haya notado ... Ahora extienda eso a la suspensión, los paneles de la carrocería, el interior, etc. No creo haberlo visto nunca Sin embargo, encontré un automóvil con el que no pude encontrar algo malo. Sin embargo, la gran mayoría de las partes son superfluas para la misión del transporte. No es así con una computadora. Casi todas las partes de una computadora son críticas.

Es el viejo debate analógico vs. digital, recién reempacado. La televisión digital es genial, siempre y cuando todo sea perfecto. En el instante en que algo sale mal, el audio tartamudea y el video se bloquea haciéndolo inútil. Compare con la televisión analógica en la que solo obtendría un pequeño silbido o estática que se ignorará fácilmente.

En primer lugar, por supuesto, algunos SW son perfectamente confiables, y los automóviles, especialmente los británicos e italianos, no son necesariamente tan confiables.

Dicho esto, mi experiencia de trabajar con software automotriz es que se reduce a dos cosas:

• Los costos de garantía. Cuando su sw falla, lo reinicia. Quizás presentará un informe de error. O use el costoso contrato de soporte. Cuando su automóvil falla, lo traerá y exigirá que se arregle bajo garantía. Esto le costará al fabricante $ 100 o más. Si cada falla de sw le cuesta al fabricante $ 2, estoy bastante seguro de que sería más confiable.

• JD Powers (y otras clasificaciones de calidad). JD Powers encuesta a ThingsGoneWrong (que podría ser cualquier cosa). Y si esa clasificación es realmente mala, la gente simplemente no comprará su automóvil, al menos no por el dinero suficiente para obtener ganancias. Si tuviéramos un JD Powers para sw y la gente realmente se preocupara por él, entonces estoy bastante seguro de que sw sería más confiable.

Por lo tanto, si fabrica automóviles poco confiables, los costos de la garantía se comerán rápidamente todas sus ganancias y, en unos pocos años, la clasificación de mala calidad significa que no venderá ningún automóvil en absoluto. Si realiza un intercambio no confiable, los usuarios se quejarán y podrá vender costosos contratos de soporte.

La fiabilidad y seguridad del vehículo motorizado es obligatoria. En muchos (¿la mayoría de los países?), La ley exige que tengan un nivel mínimo de confiabilidad y seguridad, y se les realiza la prueba para el peor de los casos (sea lo que sea). El software comercial no lo es, en su mayor parte.

Si bien existen otras implicaciones legales para el software, es importante tener en cuenta que si el software falla cada vez que presiona el botón "Guardar", entonces esto es simplemente una cuestión de parche / arreglo y luego continúa. Si un automóvil se estrella cada vez que enciende el indicador, esto es mucho peor . Simplemente no es tan importante que Microsoft Outlook se ejecute sin fallar inesperadamente, como lo es que un SUV se ejecute sin fallar inesperadamente.

Dicho esto, hay otras piezas de software que tienen tanta o más responsabilidad que la mecánica de un automóvil. Los aviones y los sistemas de guía de misiles deben ser confiables; hay vidas en juego! Uno esperaría que estos se prueben más estrictamente que el automóvil promedio.

La industria automotriz no lanza al público un automóvil "beta" para pruebas, la industria automotriz tampoco tiene que preocuparse por el entorno en el que entregan sus productos, sin embargo, tengo que preocuparme por muchas otras cosas. Digamos que la industria del software es fundamentalmente diferente (como todos sabemos), por lo que la fiabilidad y la complejidad son realmente sugerentes. En mi opinión, un automóvil es tan complejo como un software, pero es más fácil ver qué funciona o no desde

• En la parte inferior de los autos no son virtuales, seguramente será más fácil de probar (pero más costoso)
• Comenzaron mucho antes que la industria del software, incluso si fueran menos personas, no se puede minimizar la práctica y el conocimiento que reunieron. La industria del software todavía es un bebé en comparación con ella.
• Toda la industria automotriz está obligada por la ley y la ética a no fabricar automóviles que maten a su conductor, especialmente en las últimas décadas.

Entonces, la declaración que dice que el software es menos confiable que los automóviles, puede ser cierto para muchos tipos de software y completamente incorrecto para otra área (seguridad, aeronáutica ...), puede estar seguro de que un software es al menos más confiable que el más confiable de autos en esa área. Simplemente porque esas áreas son críticas y, por lo que sé, solo en esas áreas, el software puede compararse con la industria automotriz.

Lo que nos lleva a esto: la mayoría del software no se considera crítico en su dominio. Cuando se considera como tal, tiene un software confiable, el único problema que encontrará en ellos son los problemas relacionados con el entorno (por lo tanto, si puede controlarlo, prácticamente no tendrá ningún problema), no el software en sí. Sin embargo, la mayoría de los editores de software no funcionan en estas áreas críticas, por supuesto, están obligados a proporcionar un cierto nivel de calidad, pero están más obligados (en mi opinión) a entregar el software lo antes posible. Sin embargo, un buen software requiere: buena gestión de proyectos, especificaciones sólidas, buen diseño y buen nivel de habilidades de quienes trabajan en él (para resumirlo). Eso es solo para hacerlo, ni siquiera estamos hablando de venderlo ...

Todo esto lleva tiempo y requiere dinero. No digo que recibas lo que estás pagando por lo que digo. La mayoría de las veces produces lo que inviertes nunca menos (excepto si te atornillan pero luego no produces nada ...) y, a veces, más. .

No creo que los autos sean menos complejos. Pero incluso si ese es el caso, no creo que el software sea menos confiable. Sin embargo, creo que hay factores más importantes que conducen a discrepancias en la confiabilidad del software:

1. Abstracción involucrada en el software. Esto hace que los creadores de software no entiendan cómo funcionan realmente las cosas. A medida que pasa el tiempo, se agrega más y más abstracción. Por ejemplo, el lenguaje ensamblador le da control directo a la máquina. C es más abstracto pero aún está cerca de la máquina. Java, C # y lo que vendrá después son muy abstractos de lo que sucede en la máquina. Otro ejemplo es si usted es un programador que quiere comprender cómo ocurre la creación de redes en el nivel de software, entonces debe saber programar con C porque la infraestructura (como software) está escrita en C.

2. Diferentes experienciasy el conocimiento de los creadores conduce a diferentes resultados. Diferentes desarrolladores crean software con diferente confiabilidad. Lo mismo puede decirse de los fabricantes de automóviles. Sin embargo, la diferencia es que cualquiera que pueda usar un editor y un compilador o incluso simplemente instalar un IDE (Integrated Development Environment) puede crear software y de forma gratuita. Para fabricar un automóvil, necesita una gran inversión, una fábrica (algunos pueden fabricar un automóvil sin usar uno, pero no lo encontrará en todas partes). El hecho de que invierta mucho, significa que tratará de contratar a los mejores en el campo. Sin embargo, todavía hay problemas de confiabilidad con los automóviles. Si es consciente de ello, muchos millones de automóviles se retiran de los mercados por [errores] graves. En mi automóvil, el fabricante reemplazará las pinzas de freno de forma gratuita para todos los automóviles comprados en el mismo año.

3. Los errores en el software generalmente son más atractivos para los usuarios que los automóviles. Este es el resultado de la interactividad y la respuesta entre el usuario y el software. En un automóvil, prestamos atención a menos detalles como "El automóvil está acelerando cuando pisamos el acelerador", frenando, girando, luces, espejos, etc. En el software, con cada clic / entrada del usuario generalmente hay una respuesta. Por lo tanto, hay muchos puntos en los que el software puede tener errores y el usuario lo notará de inmediato. Esto hace que un usuario crea que es menos confiable que los automóviles.

4. Hackeo y ataques . Cuanto más se use un software, mayor será el porcentaje de ataques de piratería. Puede comparar esto con el robo de automóviles. Para mí, la fiabilidad de un automóvil también se ve comprometida cuando puede ser abierta por alguien que no sea su propietario o la llave. Sin embargo, es más fácil intentar atacar un software que un automóvil ya que el atacante no es visible. Entonces, cuando un software se ve comprometido, las personas asocian que no es confiable a pesar de que es confiable para lo que fue creado.

Es como todo lo demás ... cuando funciona no te importa ... cuando está roto (o no funciona de la manera que quieres / esperas) que te importa.

Piensa en aviones. Toneladas de personas están preocupadas por las personas que intentan secuestrarlas o hacerlas explotar. Pero realmente la cantidad de eventos negativos es pequeña en comparación con la cantidad de vuelos diarios. (Hay más vuelos en un día que han sido secuestrados o bombardeados ... diablos, incluso intentaron ser secuestrados o bombardeados).

Todo está en donde te ves y cómo mides.

En realidad es bastante simple. Los autos son de la vieja tecnología. Claro que hay campanas y silbatos en estos días (que se rompen), pero si miras los primeros autos, se rompieron mucho .

La 'tecnología' detrás de las partes mecánicas de los automóviles ha existido durante cientos de años y el motor de combustión interna también ha existido durante mucho tiempo, y cuando se introdujeron, había muchos problemas.

Tenga en cuenta que los problemas de memoria son casi una cosa del pasado con algunas de nuestras plataformas administradas. Déle al software un par de cientos de años y también lo tendremos definido. De hecho, considerando la complejidad del software, creo que estamos por delante de la curva.

Los automóviles modernos dependen de s / w. Cuando los automóviles modernos fallan, por ejemplo, la computadora del motor falla, generalmente (aunque no siempre, pero generalmente) es la electrónica que la cargó, no el s / w.

Pregúntele a cualquier propietario de un automóvil moderno con una ECU cuánto tiempo dura antes de una falla costosa. Me sorprendería si tienes 10 años. Los autos modernos llenos de electrónica y sensores son increíblemente poco confiables.

Si estudia la teoría de la confiabilidad, la respuesta se vuelve cegadoramente obvia. Todo lo mecánico (espere el software) tiene una confiabilidad de estado estable, que es la tasa de falla cuando se encuentra fuera de las regiones de mortalidad infantil y desgaste. La tasa de falla del artículo final es la SUMA de las tasas de falla de las partes. Agregue más partes: la tasa de falla agregada se convierte en un número mayor. El desafío, entonces, es lograr que las tasas de falla de todos esos componentes sean realmente bajas.

Cuando se trata de cosas como correas dentadas y desgaste de cilindros y sensores de oxígeno que se llenan de basura, y los conectores se vuelven óhmicos y los cables se rompen debido a la vibración, existen técnicas que pueden usarse para reducir la tasa de fallas. El costo también aumenta a medida que haces esto.

El software, por otro lado, tiene una tasa de falla constante. A pesar de la dificultad de encontrar defectos a veces, al final todo el software es una máquina de salchichas. Entradas -> Hacer cosas -> Salidas. A veces, el ORDEN de las entradas y las combinaciones de entradas conducen al fracaso con modos que son detectables. Cuando eso sucede, has encontrado tu defecto, lo arreglas y sigues adelante.

El software que no tiene defectos (conocidos) tiene efectivamente una tasa de falla de 0. Se ejecutará para siempre sin fallas. (Tiempo medio entre fallas = 1 / tasa de fallas). La plataforma de hardware fallará primero.

El software con defectos puede ejecutarse solo hasta que la combinación correcta de condiciones de entrada, con el tiempo, haga que el defecto se manifieste.

La FALACIA en todo esto es tratar de comparar las tasas de falla de las cosas físicas (causadas por el desgaste, la migración de metales en los circuitos integrados, la entrada de agua, la vibración, etc.) con una tasa de falla de lo que es esencialmente una máquina de estado finito que simplemente hace exactamente lo que su secuencia de instrucciones le dice que haga.

(Incluso cosas como voltear los bits de las partículas alfa en la RAM es un fenómeno físico, no un defecto de software. Sin embargo, la forma de manejar una situación tan uniforme PUEDE ser un defecto de software, pero recuerde que esa desagradable partícula alfa fue solo otra entrada al software. )

La diferencia entre el software y los automóviles es que para que los desarrolladores de software mantengan la cordura, todos los usuarios del software deben conducir duplicados exactos del software y para que los fabricantes de automóviles mantengan la cordura, deben aceptar que todos sus usuarios conducirán automóviles significativamente diferentes porque la forma en que conduce un automóvil cambia el automóvil, pero la forma en que utiliza el software no necesariamente cambia el software.

Por otra parte,

Si tuviera alguna forma de verificar el aceite en su software, sabría cuándo iba a fallar.

Si tuviera alguna forma de cambiar el aceite en su software, probablemente podría extender su vida útil por unos meses.

Y para extender sin sentido la analogía:

Los parches no están cambiando el aceite, están reemplazando una junta con fugas.

Las actualizaciones no están cambiando el aceite, están arreglando los frenos.

Los lanzamientos no están cambiando el aceite, son más como agregar un encendido sin llave.

Los autos que se descomponen no son tolerables. También puede poner en peligro vidas. Se tolera el software que se descompone, y los usuarios lo evitan o simplemente lo aceptan. No hay mucha demanda de software libre de errores.

Además, el software tiende a personalizarse, no tiene 10000000 modelos diferentes de automóviles. Yo diría que wikimedia es confiable y muchas personas usan ese software. Entonces, se podría decir que mucha gente usa software libre de errores o confiable. (WordPress, varios controles de fuente, mysql y sqlite son bastante confiables, etc.)

Los softwares son objetos matemáticos y lógicos, mientras que los automóviles son objetos reales.

Además, puede saber fácilmente cuándo un automóvil tiene un problema y cuál es el problema, mientras que puede ser mucho más difícil con los softwares: imagine que alguien tiene un problema con una computadora y alguien que tiene un problema con un automóvil; esta persona puede saber mejor qué sucede porque los autos son menos abstractos que las computadoras.

No digo que las computadoras sean más difíciles de entender: los automóviles también implican muchas leyes físicas como la termodinámica, la electrónica y la química.

También podría extrapolar esta comparación, diciendo: "¿por qué un martillo es más confiable que una secretaria?".

No creo que la pregunta sea realmente relevante, pero creo que muestra muy bien cómo la falta de una buena educación matemática puede afectar la comprensión de cierto tipo de sistema.

El software es mucho más complejo que un automóvil, incluso si el automóvil está compuesto por miles de componentes.

Si un automóvil fuera tan complejo como el software, entonces todos los componentes del automóvil dependerían de todos los demás componentes del automóvil, y muchos componentes del automóvil estarían directamente vinculados con muchos otros componentes del automóvil.

Todos los automóviles del mundo apenas igualan la complejidad del software original de Unix.