Pourquoi les logiciels ne sont-ils pas aussi fiables qu'une voiture? [fermé]

Un utilisateur m'a posé cette question. Nous savons que les voitures tombent en panne, mais c'est à cause de quelque chose de physique (sauf si un logiciel est impliqué!).

J'ai essayé de répondre que les logiciels étaient une industrie beaucoup plus jeune, mais l'utilisateur a rétorqué que "l'industrie automobile n'est-elle pas devenue beaucoup plus stable et fiable avec moins de personnes?".

J'ai également essayé de répondre que le logiciel est plus complexe, mais l'utilisateur a rétorqué que plusieurs milliers de pièces constituaient une voiture. Les personnes qui conçoivent et construisent des voitures connaissent généralement très bien leurs composants, mais elles finissent toujours par travailler ensemble.

Alors, pourquoi les logiciels ne sont-ils pas aussi fiables qu'une voiture?

La prémisse de votre question est tout simplement incorrecte: le logiciel n'est pas "moins fiable" qu'une voiture. Il y a des milliards d'appareils sur lesquels les logiciels intégrés fonctionnent 24 heures sur 24, 7 jours sur 7, pendant des années, sans aucun problème. Heck, certains sont dans les voitures et contrôlent / surveillent le moteur. Alors, comment un logiciel peut-il être moins fiable qu'une voiture si les voitures elles-mêmes s'appuient sur des logiciels?

Je conçois des logiciels et des pièces mécaniques.

C'est la complexité.

Parce qu'il y a des millions de "parties" dans les logiciels modernes.

Les composants logiciels sont très compliqués et comportent beaucoup d’État. Une pièce mécanique immobile n'a pas d'état.

Une pièce mobile mécanique a sa position (une variable).

Un programme en cours d'exécution utilisant 1 Mo de RAM possède un million d'octets d'état. C'est beaucoup plus que n'importe quel système mécanique normal.

Il y aura une combinaison d'états qui ne seront jamais testés car ils se produisent très rarement. Dans un système mécanique (comme une voiture), il est facile de vérifier que les pièces mécaniques ne se heurtent pas pendant le fonctionnement. Le logiciel de CAO mécanique que j'utilise au travail le fait automatiquement.

Si vous construisiez des machines à partir de pièces invisibles et non palpables, et que vous aviez des millions de pièces en mouvement manquantes, ce serait comme un simple programme.

Même "hello world" fonctionne sur un système d'exploitation. Les vieux systèmes 8 bits et les systèmes d’exploitation pour mini-ordinateurs étaient assez fiables parce qu’ils étaient simples.

Des éléments tels que les DLL et les bibliothèques partagées sont remplacés dans le cadre de mises à jour de virus ou d'installations logicielles, puis le programme qui vous intéresse ne fonctionne pas. Un peu comme changer le pneu de votre voiture pour un pneu de vélo. Certains des états périphériques de la fonction de bibliothèque interfèrent (n'agissez pas comme prévu par le programme).

Les programmes écrits dans des langages tels que Java qui n'autorisent pas de nombreuses interactions non conçues entre objets (réutilisation de pointeur, débordements de limites de tableau) sont généralement assez fiables une fois que vous les avez utilisés.
Lorsque vous utilisez des systèmes d'exploitation avec des bibliothèques statiques, une fois qu'un programme fonctionne, il continue de fonctionner (tout en conservant de nombreuses conditions de bord, en fonction de la taille de son état).

Dave Parnas écrit sur la fiabilité des logiciels en rendant l'état du programme plus petit. Les gars de la programmation fonctionnelle stricte font la même chose en forçant une assignation statique unique.

C'est une question de choix du consommateur.

Si les consommateurs demandaient un logiciel aussi fiable que ma Honda Civic (par opposition à mon ancien Ford Maverick), ce serait le cas. Certaines entreprises exigent des logiciels aussi fiables, et ils en ont, en général pour les logiciels intégrés, parfois pour des tâches critiques pour la sécurité, telles que les missions spatiales et le contrôle du trafic aérien. Le logiciel n'est toujours pas parfait, mais les voitures non plus.

Cependant, les clients exigent d’autres qualités dans leurs logiciels et ne sont généralement pas prêts à payer pour des logiciels qui sont peut-être moins fonctionnels, certainement plus chers, et qui sont expédiés plus tard simplement parce qu’ils sont plus fiables.

il y a plusieurs milliers de pièces qui composent une voiture.

Si seulement un ordinateur (et le logiciel associé) était aussi simple que cela.

L'ordinateur a quoi un gigaoctet de mémoire? Des milliards de tongs? Un téraoctet de disque? Des milliards de pièces "mobiles"?

Le logiciel peut avoir des dizaines de milliers ou des centaines de milliers de lignes individuelles de code en cours d'exécution. Plus que beaucoup (ou plus) dans les tests unitaires et les outils.

Non, l'argument "les voitures sont complexes aussi" est super. Le logiciel est beaucoup, beaucoup, beaucoup plus complexe qu'une voiture.

Les principes qui font que les moteurs à combustion fonctionnent, et tous les composants qui composent une voiture n'a pas beaucoup changé au cours du siècle dernier. Bien sûr, il y a eu des améliorations évolutives et des voitures hybrides, mais les composants de base sont les mêmes. Vous avez un moteur, une transmission, etc. Même les concept-cars et votre Bugatti Veyron extrêmement coûteuse et extrêmement rapide sont construits avec la même structure de base. En bref, concevoir une voiture est un problème bien connu .

Comparez cela avec le développement de logiciels.

• Les clients ne savent pas ce qu'ils veulent quand ils commencent. Ils commencent à parler d'un jet de luxe, mais ensuite, lorsqu'ils réalisent les coûts, ils veulent que vous le construisiez au prix d'un scooter à pédale.
• La conception d’une voiture prend des années à passer de l’idée au concept-car, et plus d’années à la fabrication. Quand était la dernière fois que vous avez eu ce luxe avec le logiciel?
• Les pièces de voiture sont des pièces moulées en métal, mais les composants logiciels peuvent souvent changer de forme et d'interface.
• Le processus de fabrication est complètement différent. Avec les voitures, les pièces sont fabriquées en quantités massives et les mêmes pièces sont utilisées dans différents véhicules. Avec les logiciels, presque tout est fabriqué à la main car sinon, tout ne rentre pas.

En bref, il y a un certain nombre de raisons pour lesquelles une voiture serait perçue comme "plus fiable" que les logiciels. Je viens de venir avec un couple.

Les voitures sont fiables. Ainsi est la plupart des logiciels.

Mais ... les voitures personnalisées et les logiciels personnalisés ont tous deux des problèmes.

N'importe quel passionné de voitures, qui a sa voiture de 1970 modifiée, ses bricolages et ses modifications, ses pannes et toutes sortes de problèmes stupides qu'il n'aurait pas eu s'il l'avait laissée originale. Mais ... alors il n'aurait pas le compresseur ...

Parce que la voiture que vous conduisez a été fabriquée à plusieurs reprises, le processus de construction est tellement perfectionné que la même voiture peut être fabriquée maintes et maintes fois.

S'il s'agissait d'une voiture de pointe complexe, unique en son genre, construite à partir de rien alors qu'elle serait loin d'être aussi fiable, par exemple, regardez combien le taux d'échec est plus élevé dans les voitures de course de formule 1. Il est courant qu'un ou deux se décomposent par course.

Un nouveau logiciel est toujours unique. Ce que le code des programmeurs n'a jamais été codé par eux auparavant. Pour obtenir une qualité vraiment élevée dans ce scénario, le coût est prohibitif pour la plupart des produits. Chaque nouveau logiciel non trivial est en réalité un prototype.

Soit dit en passant, c'est l'une des principales raisons pour lesquelles l'application des techniques d'ingénierie traditionnelles au génie logiciel est un désastre.

1. Les constructeurs automobiles obtiennent les spécifications complètes avant de produire le produit "final".
2. Les automobilistes n'ont pas tendance à faire des choses stupides auxquelles les concepteurs ne s'attendaient pas.
3. Les voitures ne sont "mises à jour" qu'une fois par an (généralement), alors que la plupart des logiciels devraient être mis à jour plusieurs fois par an.

Je pourrais continuer, mais mon navigateur a l’impression d’être sur le point de planter ...

Il y a en fait une raison très simple.

Un logiciel qui rapporte de l'argent est un logiciel qui gagne des parts de marché. Plus souvent qu'autrement, la société qui commercialisera un logiciel sur le marché en premier sera celle qui obtiendra la plus grande part du marché, même si leur logiciel n'est pas le meilleur produit de leur marché.

Par conséquent, l’accent est mis sur la publication des logiciels plus rapidement et imparfaitement, plutôt que plus tard et parfaite.

J'aime la plupart des réponses jusqu'à présent. Voici mon tour sur elle.

Le coût en cas d’échec est plus élevé pour les voitures que pour les logiciels

Une panne de voiture pourrait potentiellement coûter une vie. Même une panne de véhicule ne mettant pas la vie en danger représente un inconvénient très visible pour l'utilisateur. Une défaillance logicielle signifie simplement que certaines ressources de support de production insuffisantes devront faire des heures supplémentaires. Et si cette personne est un employé exempté à plein temps, alors ça alors, ce n'est pas si cher que ça. En fait, la mauvaise qualité et la mauvaise gestion sont récompensées car les heures supplémentaires gratuites réduisent réellement le coût du travail à l'heure!

Bien sûr, cela dépend du type de logiciel utilisé (les logiciels alimentant des systèmes d'armes, l'avionique ou les systèmes médicaux peuvent également avoir un impact sur la vie), mais une voiture coûte cher et est utilisée régulièrement, de sorte que les défaillances en matière de fiabilité sont insuffisantes. tout à fait tangible et douloureux. Les échecs logiciels ont souvent des solutions de contournement.

Une autre pensée: les voitures semblent fiables, mais elles ont des coûts de maintenance fixes qui sont en cours, même si la voiture fonctionne bien, et culturellement, cela est accepté et même une dépense orgueilleuse pour ceux qui se soucient de leurs véhicules. Les logiciels, par contre, sont souvent endommagés lors de l’installation et doivent souvent changer au fil du temps, mais culturellement, personne ne veut payer pour la maintenance.

Eh bien, les voitures étaient assez peu fiables pour la plupart de leur histoire, et il y a certainement une courbe d'apprentissage. Les voitures sont produites à grande échelle depuis environ 60 ans, alors que les logiciels ne sont produits à grande échelle que pendant 20 à 25 ans. Par grande échelle, je veux dire fondamentalement assez large pour que les masses l'achètent / l'utilisent et il y a vraiment une incitation énorme à trouver comment perfectionner la procédure pour la créer.

J'aime penser à la voiture comme une application. Alors que l'OS est la route sur laquelle l'application s'exécute.

L'interface entre la route et la voiture est bien définie. Bien testé et soumis à une vérification approfondie de la compatibilité ascendante (ce qui est simple car l'interface est simple). Mais malgré cela, vous avez des problèmes de compatibilité descendante. Les voitures de type "Farrie" ont du mal à rouler sur des routes de type "routes de boue".

Même si votre système d'exploitation, tout comme les routes, nécessite un entretien constant. Les ponts sortent. Les voitures mettent des chaînes à neige et déchirent les routes comme une application corrompue et endommagent les disques et les fichiers utilisés par le système d'exploitation.

Les applications seront écrites sur un système d'exploitation. Mais en général, ils doivent exécuter différentes versions du système d'exploitation (différents types de route). Ainsi, votre application optimisée pour le souper peut fonctionner sans problème et sans problèmes tant qu'elle est exécutée sur le bon système d'exploitation (autoroutes), tandis que les autres codes d'usage général (plus simples) fonctionnent correctement sur tous les types de route.

L'interface entre l'application et le système d'exploitation est définie mais extrêmement complexe et fluctue toujours légèrement. D'autant plus que nous permettons à l'utilisateur de modifier son propre système d'exploitation avec des extensions. Si le gouvernement permettait aux utilisateurs de modifier les routes, il y aurait beaucoup plus de collisions.

Lorsque vous commencez à limiter la capacité de l'utilisateur à modifier le système d'exploitation, la fiabilité des applications peut devenir quasi solide. Regardez tous ces appareils intégrés. Nous ne laissons pas les utilisateurs s'approcher de leur système d'exploitation et ils courent sans interruption 24 heures sur 24, 7 jours sur 7, sans interruption.

Je dirais donc que ce n’est pas ce logiciel qui n’est pas fiable. Cela revient plus à dire que les utilisateurs creusent des trous dans l’autoroute pour les applications. Hé, votre application vient de s'écraser dans le trou que j'ai creusé l'année dernière et que j'ai oublié .

Premièrement, votre utilisateur doit savoir qu’il existe dans ce monde un logiciel tellement fiable qu’il n’en a même pas conscience. Avez-vous déjà vu un crash de télévision? Moi non plus.

Je pense que la raison principale est que le logiciel est immatériel. Être immatériel signifie que les non-développeurs ne voient pas les progrès se poursuivre. Par exemple, si je construisais une voiture, vous pourriez me voir assembler les différentes pièces et cela ressemblerait de plus en plus à une voiture; Cependant, si vous regardez ma programmation, je passerai peut-être des heures à maudire un écran noir avec du texte vert faisant des motifs étranges, puis tout à coup, lorsque le motif changera un petit peu, je surexciterai.

À cause de cela, les gens normaux ne réalisent pas la complexité des logiciels. Quand ils voient une fenêtre, ils pensent voir le programme dans son ensemble, ce qui est tellement mauvais.

En outre, les logiciels sont beaucoup, beaucoup plus souvent fortement personnalisés que les voitures. Lorsque vous personnalisez une voiture, vous n'allez pas contre son design, car ce serait visiblement stupide. Si mon moteur est à l'avant de la voiture, le déplacer à l'arrière sera probablement un désastre majeur. Cependant, étant donné que les logiciels sont immatériels, si le client vous demande de faire quelque chose de complètement contre la conception, il n’obtiendra aucune indication (sauf vous, mais ils ne l’écouteront pas) que ce qu’ils font est stupide, puis ils " Je suis surpris que cela ne fonctionne pas comme prévu.

1. Manque de partage d'informations (les programmeurs volent seuls ou en petits groupes - les concepteurs de voitures travaillent avec des équipes interconnectées au sein d'une grande entreprise et partagent leur savoir; si nous travaillions tous pour de grandes entreprises, nous serions tous de meilleurs programmeurs grâce à l'apprentissage C’est aussi pourquoi les choses comme les programmes open-source et les ressources en ligne sont très importantes)
2. Attentes des participants sur le terrain (ce n’est pas grave si un designer automobile n’est utile que de façon marginale pendant les 5 à 10 premières années, mais si un programmeur passe une interview et dit qu’il ne sera pas très utile pendant 5 à 10 ans, le l'interview est terminée)
3. Absence de test de pénétration (manque de fonds, problèmes de légalité, etc.; les constructeurs automobiles, toutefois, claquent voiture après voiture dans un mur de briques, ont des souffleries, ont des exigences de performance relativement simples, etc.)
4. Transparence de l'information (vous ne savez pas comment fonctionne la plupart des logiciels; vous devinez ou vous vous appuyez sur des hypothèses basées sur des entretiens, des communiqués de presse, des publicités, etc.; avec les voitures, cependant, la plupart des éléments sont là pour que vous les regardiez)
5. Encapsulation inhérente des connaissances (l'homme / le robot soudant le cadre ensemble n'a pas besoin de connaître les mathématiques derrière le système de contrôle de la stabilité; les programmeurs doivent être informés sur des milliers ou des dizaines de milliers de choses inconnues de l'homme moyen, alors que besoin de connaître des centaines ou des milliers)
6. La tangibilité (ça aide quand on peut le voir)
7. Age of Field (la conception du véhicule remonte à des milliers d'années; la conception du véhicule motorisé a plus de 250 ans [moteur à vapeur, etc.])
8. Criticité des sous-systèmes (les voitures continueront de fonctionner, même si bon nombre de leurs composants cessent de fonctionner: verrous électriques, vitres électriques, CVCA, essuie-glaces, vitres brisées, enjoliveurs perdus, pneus crevés, un poste de radio, une lumière ou deux, entrée à distance, etc .; quand quelque chose sur un ordinateur se brise, c'est souvent un scénario SHTF)
9. Interdépendance (lorsqu'un ordinateur tombe en panne, il n'est pas rare qu'il affecte des centaines, voire des milliers d'autres ordinateurs; lorsqu'un véhicule tombe en panne, il est plutôt rare que d'autres voitures soient affectées. Si d'autres voitures sont affectées, ce n'est presque toujours 1 -3)
10. Blâme généralisé (si une partie d'un ordinateur ou un ordinateur parmi des milliers casse et blesse un système, le blâme s'étend à tout l'ordinateur, ou, dans ce dernier cas, à l'ensemble du réseau d'ordinateurs; si votre voiture est heurtée par une freins défaillants, ou si une voiture cale et ne redémarre pas sur l'autoroute, seule la pièce individuelle de la voiture est mise en cause)
11. Systèmes finis contre systèmes infinis (les voitures ne peuvent avoir qu'un nombre limité de personnes et ne sont censées fonctionner que dans des conditions limitées - par exemple, vous ne conduisez pas une BMW sur un terrain que seul un véhicule de type Jeep peut faire; avec un ordinateur, cependant, les possibilités sont de facto infinies - il y a constamment de nouvelles choses, de nouvelles API, de nouveaux systèmes d'exploitation, de nouvelles failles de sécurité, des iPads, des logiciels de téléphonie mobile, des nouveautés, des nouveautés, etc.)
12. Portée du corpus de connaissances requis (une personne ayant un QI de 130 à 140 pourrait apprendre presque tout ce qu'il y a à savoir sur les voitures, mais ne pourrait apprendre qu'une fraction de ce qu'il y a à savoir sur les ordinateurs et la programmation)

La simple raison pour laquelle toute la logique est erronée:

Les dispositifs mécaniques peuvent être simplement réduits en entrée / sortie ; L'augmentation du nombre de pièces pour obtenir cette opération d'E / S ne modifie pas l'opération d'E / S. Ainsi, le système peut être entièrement compris.

Le logiciel quant à lui a Entrée -> Processus -> Sortie . En raison de cette nature, le système ne peut être entièrement prédit ou compris.

Donald Rumsfeld a dit le mieux:

«Il y a des connus connus; il y a des choses que nous savons que nous savons. Nous savons également qu'il existe des inconnus connus; c'est-à-dire que nous savons qu'il y a des choses que nous ne savons pas. Mais il y a aussi des inconnus inconnus - ceux que nous ne savons pas que nous ne savons pas. ”- Donald Rumsfeld, secrétaire américain à la Défense

En résumé:

• Un dispositif mécanique est un système qui a connu, et connu-inconnus,
• Le logiciel a ce qui précède, mais aussi des inconnus inconnus.

C'est une question stupide (pas de vous, mais de la personne d'origine).

Cela ressemble à mon père (un mécanicien) qui déteste les ordinateurs, mais passe toute la journée sur eBay.

C'est comme demander "Pourquoi un arbre est-il plus fiable qu'un papillon de nuit?".

Tout d’abord, je possède 30 ordinateurs (et plus de 30) et aucun d’entre eux n’a été dans le magasin. Je viens de dépenser 1400 $ sur ma voiture en réparations. Allez compter le nombre d’ateliers de réparation automobile par rapport à la réparation d’ordinateurs. Encore une fois, analogie stupide.

Les voitures sont en acier, les ordinateurs en plastique. Les voitures fonctionnent dans toutes les conditions météorologiques, des ordinateurs conçus pour une utilisation en intérieur.

Mon Commodore 64 (26 ans) fonctionne parfaitement et n'a pas été réparé. Mes deux véhicules (âgés de moins de 10 ans) ont subi des réparations très importantes. Montrez-moi une voiture avec des milliers et des milliers d’heures d’utilisation, âgée de 26 ans, qui fonctionne toujours à 100% comme elle le faisait quand elle était neuve.

Le logiciel est basé sur les bits: 0 et 1. Les voitures sont basées (principalement) sur des pièces mécaniques.

Une pièce mécanique peut s'user ou mal fonctionner et encore un travail. Vos freins s'usent ou une valve fuit, mais la voiture fonctionne encore jusqu'à ce que vous puissiez la faire réparer.

Les logiciels, pour la plupart, n'ont pas d'échec progressif. Ça marche ou ça casse. La division par zéro n'est pas "presque correcte"; c'est juste une erreur. Lorsque vous essayez de sauvegarder sur un lecteur sans suffisamment d'espace, vous ne pouvez pas forcer pour forcer toutes les données; ça ne va tout simplement pas.

Je ne pense pas qu'un logiciel soit nécessairement moins fiable qu'une voiture, mais lorsqu'un logiciel échoue, il échoue immédiatement, pas progressivement.

Je pense avoir une bien meilleure analogie. Prenez une entreprise qui construit des ambulances selon les spécifications du client. La plate-forme de base (par exemple, un châssis de véhicule récréatif entièrement opérationnel et conforme aux lois de la rue) nécessite des modifications à plusieurs points: cadre, système de charge, goulotte de remplissage, suspension, etc. Ces modifications doivent non seulement être légales sur la route, mais également répondre aux exigences des juridictions tout en satisfaisant les désirs des clients.

Ensuite, vous devez construire le corps de l'ambulance lui-même, qui est également soumis à des exigences réglementaires de plusieurs niveaux de gouvernement et d'autres organismes. Tout en satisfaisant les désirs du client, certains arrangements de sièges ou systèmes de rangement géniaux Et n'oubliez pas que vous avez une centaine de clients différents du monde entier suivant des calendriers d'achat et de déploiement différents. Aucun d'entre eux ne dit jamais: "Je vais en prendre une douzaine de plus, tout comme le dernier", sans également soumettre des pages d'exceptions qui nécessitent souvent une réingénierie complète de l'ensemble.

Voitures? C'est trivial. Vous achèterez ce qui a été construit et vous n’avez d’impact direct sur aucun aspect de la conception. Même votre choix de couleur est artificiel car vous ne pouvez pas spécifier quelque chose qui n'a pas encore été conçu et testé. Dans un certain sens, il n’ya qu’un «marché» et non un «client». Je dirais que les logiciels disponibles sur le marché sont généralement aussi fiables que la voiture que vous achetez chez le concessionnaire local.

Les voitures ne sont pas aussi fiables que vous le pensez. C'est juste que les fautes peuvent rester cachées pendant un long moment (ou être ignorées) sans que tout cela échoue. Votre voiture a-t-elle une fuite d'huile et / ou de liquide de refroidissement? Non? Êtes-vous sûr? Vous vous trompez probablement ... Il s'agit probablement d'une très petite fuite quelque part que vous n'avez pas encore remarquée ... Maintenant, étendons cela à la suspension, aux panneaux de carrosserie, à l'intérieur, etc. Je ne pense pas avoir jamais encore rencontré une voiture que je ne pouvais pas trouver quelque chose qui ne va pas. Cependant, la grande majorité des pièces sont superflues à la mission de transport. Pas si avec un ordinateur. Presque chaque partie d'un ordinateur est critique.

C'est le vieux débat analogique / numérique, juste reconditionné. La télévision numérique est géniale, tant que tout est parfait. Dès que quelque chose ne va pas, le son bégaie et la vidéo se bloque, la rendant inutilisable. Comparez avec la télévision analogique où vous obtenez juste un petit sifflement ou statique qui est facilement ignoré.

Premièrement, certains sw sont parfaitement fiables, et les voitures, notamment britanniques et italiennes, ne sont pas nécessairement aussi fiables.

Cela dit, mon expérience avec les logiciels automobiles est qu’il s’agit de deux choses:

• Frais de garantie. Lorsque votre sw échoue, vous le redémarrez. Peut-être que vous allez déposer un rapport de bogue. Ou utilisez le contrat de support coûteux. Lorsque votre voiture tombe en panne, vous l'amenez et exigez qu'elle soit réparée sous garantie. Cela coûtera au fabricant 100 $ et plus. Si chaque échec coûte 2 dollars au fabricant, je suis convaincu que celui-ci serait plus fiable.

• JD Powers (et autres classements de qualité). JD Powers enquête sur ThingsGoneWrong (qui pourrait être n'importe quoi). Et si ce classement est vraiment mauvais, les gens n'achèteront tout simplement pas votre voiture, du moins pas pour assez d'argent pour faire un profit. Si nous avions un JD Powers pour sw et que les gens s'y intéressaient vraiment, je suis persuadé que sw serait plus fiable.

Donc, si vous fabriquez des voitures peu fiables, les coûts de la garantie grugeront rapidement tous vos profits et, dans quelques années, un mauvais classement en termes de qualité signifie que vous ne vendrez aucune voiture du tout. Si vous faites des sw non fiables, les utilisateurs se plaindront et vous pourrez vendre des contrats de support coûteux.

La fiabilité et la sécurité des véhicules à moteur sont obligatoires. Dans de nombreux pays (la plupart?), La loi impose à ceux-ci un minimum de fiabilité et de sécurité, et ils sont testés pour le pire des cas (peu importe le type). Les logiciels commerciaux ne sont pas, pour la plupart.

Bien qu'il existe d'autres implications légales pour les logiciels, il est important de noter que si le logiciel se bloque à chaque fois que vous appuyez sur le bouton "Enregistrer", il ne vous reste plus qu'à mettre à jour un correctif / correctif. Si une voiture se bloque à chaque fois que vous allumez l'indicateur, c'est bien pire . Il n’est tout simplement pas si important pour Microsoft Outlook de fonctionner sans panne inattendue que pour un SUV de s’exécuter sans panne inattendue.

Cela étant dit, il existe d'autres logiciels qui ont autant ou plus de responsabilités que la mécanique d'une voiture. Les systèmes de guidage des avions et des missiles doivent être fiables; il y a des vies en jeu! On peut espérer que ceux-ci sont testés plus rigoureusement que la voiture moyenne.

L’industrie automobile ne publie pas de voiture «bêta» au public à des fins d’essais. L’industrie automobile n’a pas à s’inquiéter de l’environnement dans lequel elle distribue ses produits, mais elle doit aussi s’inquiéter de beaucoup Dire que l'industrie du logiciel est d'abord fondamentalement différente (comme nous le savons tous), la fiabilité et la complexité sont donc très suggestives. A mon avis une voiture aussi complexe qu'un logiciel mais il est plus facile de voir ce qui fonctionne ou non depuis

• Au bas des voitures ne sont pas virtuelles, il sera forcément plus facile à tester (mais plus cher)
• Ils ont commencé beaucoup plus tôt que l'industrie du logiciel, même s'ils étaient moins nombreux, vous ne pouvez pas minimiser les pratiques et les connaissances qu'ils ont collectées. L'industrie du logiciel est encore un bébé comparé à elle.
• La loi et l’éthique imposent à l’ensemble de l’industrie automobile de ne pas fabriquer une voiture qui tue son conducteur, en particulier au cours des dernières décennies.

Donc, l'affirmation selon laquelle un logiciel est moins fiable que les voitures, peut être vraie pour de nombreux types de logiciels et totalement fausse pour d'autres domaines (sécurité, aéronautique ...), vous pouvez être sûr qu'un logiciel est au moins plus fiable que le plus fiable. des voitures dans ces domaines. Tout simplement parce que ces domaines sont critiques et que je ne connais que ces domaines, les logiciels peuvent se comparer au secteur automobile.

Ce qui nous amène à ceci: la plupart des logiciels ne sont pas considérés comme critiques dans leur domaine. Lorsque vous le considérez comme tel, vous avez un logiciel fiable, le seul problème que vous rencontrerez sont des problèmes liés à l'environnement (donc si vous pouvez le contrôler, vous n'aurez pratiquement aucun problème), pas le logiciel lui-même. Cependant, la plupart des éditeurs de logiciels ne fonctionnent pas dans ces domaines critiques. Bien sûr, ils sont tenus de fournir un certain niveau de qualité, mais ils sont plus tenus (à mon avis) de fournir le logiciel le plus rapidement possible. Cependant, un bon logiciel nécessite: une bonne gestion de projet, des spécifications solides, une bonne conception et un bon niveau de compétences de la part de ceux qui y travaillent (pour le reprendre). C'est juste pour le faire, nous ne parlons même pas de le vendre ...

Tout cela prend du temps et nécessite donc de l'argent. Je ne dis pas que vous obtenez ce que vous payez pour ce que je dis la plupart du temps, vous produisez ce pour quoi vous investissez pour jamais moins (sauf si vous êtes foutu mais vous ne produisez rien alors ...) et parfois plus. .

Je ne crois pas que les voitures sont moins complexes. Mais même si c'est le cas, je ne pense pas que ce logiciel soit moins fiable. Cependant, je pense que des facteurs plus importants conduisent à des écarts de fiabilité des logiciels:

1. Abstraction impliquée dans le logiciel. Cela provoque une mauvaise compréhension par les créateurs de logiciels du fonctionnement réel des choses. Au fil du temps, de plus en plus d'abstraction est ajoutée. Par exemple, le langage d'assemblage vous donne le contrôle direct sur la machine. C est plus abstraite mais reste proche de la machine. Java, C # et ce qui va suivre seront très abstraits ce qui se passe dans la machine. Un autre exemple est que si vous êtes un programmeur qui souhaite comprendre comment fonctionne la mise en réseau au niveau logiciel, vous devez savoir programmer avec C, car l'infrastructure (en tant que logiciel) est écrite en C.

2. Différentes expérienceset la connaissance des fabricants conduit à des résultats différents. Différents développeurs créent des logiciels avec une fiabilité différente. La même chose peut être dite à propos des constructeurs automobiles. Cependant, la différence est que toute personne qui peut utiliser un éditeur et un compilateur ou même simplement installer un IDE (environnement de développement intégré) peut créer un logiciel Et gratuitement. Pour fabriquer une voiture, il faut un investissement énorme, une usine (certains peuvent fabriquer une voiture sans en utiliser une, mais vous ne la trouverez pas partout autour de vous). Le fait que vous investissiez énormément signifie que vous essayerez de recruter les meilleurs sur le terrain. Cependant, il y a toujours des problèmes de fiabilité avec les voitures. Si vous en êtes conscient, plusieurs millions de voitures sont retirées des marchés pour cause de [bogues] graves. Dans ma voiture, le fabricant remplacera gratuitement la tondeuse de frein pour toutes les voitures achetées au cours de la même année.

3. Les bogues logiciels sont généralement plus apparents aux utilisateurs que les voitures. Ceci est le résultat de l'interactivité et de la réponse entre l'utilisateur et le logiciel. Dans une voiture, nous faisons attention à moins de détails comme "La voiture accélère quand on appuie sur la pédale d'accélérateur", casser, tourner, feux, rétroviseurs, etc. etc. Dans le logiciel, chaque clic / entrée d'utilisateur est généralement une réponse. Donc, il y a beaucoup de points où le logiciel peut être bogué et l'utilisateur le remarquera immédiatement. Cela fait croire à l'utilisateur qu'il est moins fiable que les voitures.

4. Piratage et attaques . Plus un logiciel est utilisé largement, plus le pourcentage d'attaques de piratage informatique sera élevé. Vous pouvez comparer cela au vol de voiture. Pour moi aussi, la fiabilité d'une voiture est compromise lorsqu'elle peut être ouverte par quelqu'un d'autre que son propriétaire ou sa clé. Cependant, il est plus facile d'essayer d'attaquer un logiciel qu'une voiture car l'attaquant n'est pas visible. Ainsi, lorsqu'un logiciel est compromis, les gens associent qu'il n'est pas fiable, même s'il est fiable dans le but pour lequel il a été conçu.

C'est comme tout le reste ... quand ça marche, on s'en fout ... quand c'est cassé (ou que ça ne marche pas comme on veut / attend), on s'en fout.

Pensez aux avions. Des tonnes de personnes craignent que des personnes essaient de les détourner ou de les faire exploser. Mais en réalité, le nombre d'événements négatifs est minime comparé au nombre de vols quotidiens. (Il y a plus de vols en un jour que jamais alors ils ont été détournés ou bombardés. Diable même tenté d'être détourné ou bombardé.)

Tout est là où vous regardez et comment vous mesurez.

C'est en fait assez simple. Les voitures sont de la vieille technologie. Bien sûr, il y a des cloches et des sifflets ces jours-ci (cette rupture), mais si vous regardez les premières voitures, elles se sont beaucoup cassées .

La «technologie» sous-jacente aux composants mécaniques des voitures existe depuis des centaines d'années et le moteur à combustion interne existe aussi depuis longtemps, et lors de leur introduction, de nombreux problèmes se posaient.

Considérez que les problèmes de mémoire sont presque une chose du passé avec certaines de nos plateformes gérées. Donnez quelques centaines d’années au logiciel et nous l’aurons aussi. En fait, compte tenu de la complexité des logiciels, je pense que nous sommes en avance sur la courbe.

Les voitures modernes reposent sur s / w. Lorsque les voitures modernes échouent, par exemple l’ordinateur moteur, c’est généralement (bien que pas toujours, mais habituellement) que l’électronique le répercute, pas le s / w.

Demandez à n'importe quel propriétaire d'une voiture moderne dotée d'un écu combien de temps il reste avant un échec coûteux. Je serai abasourdi si vous avez 10 ans. Les voitures modernes pleines d'électronique et de capteurs sont incroyablement peu fiables.

Si vous étudiez la théorie de la fiabilité, la réponse devient évidente. Tout ce qui est mécanique (logiciel attendu) a une fiabilité à l'état stable qui est le taux d'échec en dehors des régions de mortalité infantile et d'usure. Le taux d'échec du produit final est la somme des taux d'échec des pièces. Ajoutez plus de pièces: le taux de défaillance global devient un nombre plus élevé. Le défi consiste alors à obtenir un taux de défaillance de tous ces composants très bas.

En ce qui concerne des choses telles que les courroies dentées et l'usure des cylindres, les capteurs d'oxygène, les connecteurs qui deviennent ohmiques et les ruptures de fils dues aux vibrations, il existe des techniques qui peuvent être utilisées pour réduire le taux de défaillance. Le coût augmente également lorsque vous faites cela.

Les logiciels, en revanche, ont un taux d'échec constant. Malgré la difficulté de trouver des défauts parfois, tous les logiciels sont finalement des machines à saucisse. Entrées -> Faire des choses -> Sorties. Parfois, ORDER des entrées et des combinaisons d’entrées conduit à une défaillance des modes détectables. Lorsque cela se produit, vous avez trouvé votre défaut, vous le corrigez et vous poursuivez.

Un logiciel ne présentant aucun défaut (connu) a effectivement un taux d'échec de 0. Il fonctionnera indéfiniment sans échec. (Temps moyen entre les échecs = 1 / taux d'échec). La plate-forme matérielle va échouer en premier.

Les logiciels présentant des défauts peuvent ne fonctionner que jusqu'à ce que la combinaison correcte des conditions d'entrée rende le défaut manifeste.

La FALLACY consiste à essayer de comparer les taux d’échec des objets physiques (usure, migration du métal dans les circuits intégrés, pénétration d’eau, vibrations, etc.) et le taux d’échec de ce qui est essentiellement une machine à états finis ce que sa séquence d'instructions lui dit de faire.

(Même des choses telles que le basculement de bits de particules alpha dans la RAM sont un phénomène physique, pas un défaut de logiciel. La manière de gérer une telle soirée PEUT cependant être un défaut de logiciel, mais rappelez-vous que la particule alpha désagréable était juste une autre entrée du logiciel. )

La différence entre les logiciels et les voitures réside dans le fait que, pour que les développeurs de logiciels conservent leur santé mentale, tous les utilisateurs du logiciel doivent en reproduire exactement le contenu. Pour que les constructeurs automobiles puissent conserver leur santé mentale, ils doivent accepter que tous leurs utilisateurs conduisent. des voitures très différentes car la façon dont vous conduisez change de voiture, mais la façon dont vous utilisez un logiciel ne change pas nécessairement le logiciel.

D'autre part,

Si vous aviez un moyen de vérifier l’huile dans votre logiciel, vous sauriez quand il échouerait.

Si vous aviez un moyen de changer l'huile dans votre logiciel, vous pourriez probablement prolonger sa durée de vie de quelques mois.

Et pour prolonger inutilement l'analogie:

Les patchs ne changent pas l'huile, ils remplacent un joint qui fuit.

Les mises à jour ne changent pas l'huile, elles réparent les freins.

Les rejets ne changent pas l'huile, ils ressemblent davantage à un allumage sans clé.

Les voitures qui tombent en panne ne sont pas tolérables. En outre, cela peut mettre des vies en danger. Les logiciels en panne sont tolérés et les utilisateurs les contournent ou l'acceptent simplement. Il n'y a pas beaucoup de demande pour un logiciel sans bug.

De plus, le logiciel a tendance à être personnalisé, vous n'avez pas 10000000 modèles de voitures différents. Je dirais que Wikimedia est fiable et que des tonnes de personnes utilisent ce logiciel. On pourrait donc dire que beaucoup de gens utilisent des logiciels sans bug ou fiables. (Wordpress, divers contrôles de sources, mysql et sqlite sont assez fiables, etc.)

Les logiciels sont des objets mathématiques et logiques, alors que les voitures sont des objets réels.

De plus, vous pouvez facilement savoir quand une voiture a un problème et quel est le problème, alors que cela peut être beaucoup plus difficile avec les logiciels: imaginez une personne qui a un problème avec un ordinateur et une autre; cette personne peut mieux savoir ce qui ne va pas car les voitures sont moins abstraites que les ordinateurs.

Je ne dis pas que les ordinateurs sont plus difficiles à comprendre: les voitures impliquent également de nombreuses lois physiques telles que la thermodynamique, l'électronique, la chimie.

Vous pouvez également extrapoler cette comparaison en disant: "Pourquoi un marteau est-il plus fiable qu'un secrétaire?".

Je ne pense pas que la question soit vraiment pertinente, mais je pense que cela montre très bien à quel point l’absence d’un bon enseignement en mathématiques peut affecter la compréhension d’un certain type de système.

Le logiciel est beaucoup plus complexe qu'une voiture, même si la voiture est composée de milliers de composants.

Si une voiture était aussi complexe qu'un logiciel, alors tous les composants de la voiture dépendraient de tous les autres composants de la voiture, et de nombreux composants de la voiture seraient directement liés à de nombreux autres composants de la voiture.

Toutes les voitures du monde égalent à peine la complexité du logiciel Unix d'origine.