Pourquoi un logiciel n'est-il pas aussi fiable qu'une voiture?
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 le logiciel est une industrie beaucoup plus jeune, mais l'utilisateur a répliqué par "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é qu'il existe plusieurs milliers de pièces qui composent une voiture. Les gens qui conçoivent et construisent des voitures connaissent généralement très bien leurs composants, mais ils finissent tous par travailler ensemble comme résultat final.
Alors, pourquoi le logiciel n'est-il pas aussi fiable qu'une voiture?
La prémisse de votre question est tout simplement incorrecte: un logiciel n'est pas "moins fiable" qu'une voiture. Il y a des milliards et des milliards d'appareils qui exécutent des logiciels intégrés 24h/24 et 7j/7, pendant des années, sans aucun problème. Heck, certains d'entre eux sont in 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 dépendent du logiciel?
Je conçois des logiciels et des pièces mécaniques.
C'est la complexité.
Parce qu'il y a des millions de "pièces" dans les logiciels modernes.
Les parties logicielles sont très compliquées et ont beaucoup d'ETAT. Une pièce mécanique non mobile n'a pas d'état.
Une pièce mobile mécanique a sa position (une variable).
Un programme qui fonctionne et utilise 1 Mo de RAM a un million d'octets d'état. C'est bien plus d'état que n'importe quel système mécanique normal.
Il y aura une combinaison d'états qui ne seront jamais testés parce qu'ils se produisent si 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 mécanique CAD que j'utilise au travail le fait automatiquement.
Si vous construisez des machines à partir de pièces invisibles et non palpables et que vous avez des millions de pièces mobiles qui se manquent toutes, ce serait comme un programme simple.
Même "bonjour le monde" fonctionne sur un système d'exploitation. Les anciens systèmes 8 bits et les systèmes d'exploitation pour mini-ordinateurs étaient assez fiables car ils étaient simples.
Des choses comme les DLL et les bibliothèques partagées sont remplacées dans le cadre des mises à jour de virus ou des installations de logiciels, puis le programme d'intérêt ne fonctionne pas. Un peu comme changer le pneu de votre voiture pour un pneu de vélo. Certains états Edge de la fonction de bibliothèque interfèrent (n'agissent pas de la manière attendue par le programme).
Les programmes écrits dans des langages tels que Java qui ne permettent pas de nombreuses interactions non conçues entre les objets (réutilisation de pointeurs, débordements de limites de tableaux)) sont généralement assez fiables une fois que vous les faites fonctionner.
Lorsque vous utilisez des systèmes d'exploitation avec des bibliothèques statiques, une fois qu'un programme fonctionne, il continue de fonctionner (mais aura toujours beaucoup de conditions Edge, en fonction de sa taille d'état).
Dave Parnas écrit sur la fiabilité des logiciels en réduisant l'état du programme. Les gars de la programmation fonctionnelle stricte font la même chose en forçant une seule assignation statique.
C'est une question de choix du consommateur.
Si les consommateurs exigeaient que les logiciels soient aussi fiables que ma Honda Civic (par opposition à ma vieille Ford Maverick), ce serait le cas. Certaines organisations exigent des logiciels aussi fiables, et ils l'obtiennent, généralement pour des logiciels embarqués, parfois pour des choses critiques pour la sécurité comme 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 livré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 quel gigaoctet de mémoire? Des milliards de tongs? Un téraoctet de disque? Des milliards de pièces "en mouvement"?
Le logiciel peut avoir des dizaines de milliers ou des centaines de milliers de lignes de code individuelles en cours d'exécution. Plus que beaucoup (ou plus) de tests unitaires et d'outils.
Non. L'argument "les voitures sont complexes aussi" est superposé. Un logiciel est beaucoup, beaucoup, beaucoup plus complexe qu'une voiture.
Les principes qui font fonctionner les moteurs à combustion et tous les composants qui composent une voiture n'ont 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, un groupe motopropulseur, etc. En bref, la conception d'une voiture est un problème bien conn.
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 quand ils réalisent les coûts, ils veulent que vous le construisiez pour le prix d'un scooter à pied.
- La conception d'une voiture prend des années pour passer de l'idée au concept-car, et plus d'années pour passer de là à la fabrication. À quand remonte la dernière fois que vous avez eu ce luxe avec un logiciel?
- Les pièces automobiles sont des pièces métalliques coulées, 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 grande quantité et les mêmes pièces sont utilisées sur différents véhicules. Avec le logiciel, presque tout est fait à la main, car sinon, tout ne rentre pas.
En bref, il existe un certain nombre de raisons pour lesquelles une voiture serait perçue comme "plus fiable" qu'un logiciel. Je viens de trouver un couple.
Les voitures sont fiables. Il en va de même pour la plupart des logiciels.
Mais ... les voitures personnalisées et les logiciels personnalisés ont tous deux leurs problèmes.
Tout vrai passionné de voiture, qui a sa voiture de muscle modifiée de 1970, des bricolages et des réglages, et a des 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 si raffiné que la même voiture peut être fabriquée à plusieurs reprises sur une ligne de production.
S'il s'agissait d'une voiture de coupe complexe unique en son genre construite à partir de zéro, elle serait loin d'être aussi fiable, par exemple, regardez à quel point le taux d'échec est plus élevé dans les voitures de course de formule 1. Il est courant qu'un ou deux tombent en panne par course.
Un nouveau logiciel est toujours unique. Ce que les programmeurs codent n'a jamais été codé par eux auparavant. Obtenir une qualité vraiment élevée dans ce scénario implique un coût prohibitif pour la plupart des produits. Chaque nouveau logiciel non trivial est en fait 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.
- Les constructeurs automobiles obtiennent toutes les spécifications avant de produire le produit "final".
- Les utilisateurs d'automobiles n'ont pas tendance à faire des choses stupides auxquelles les concepteurs ne s'attendaient pas.
- 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 qu'il est sur le point de planter ...
Il y a en fait une raison très simple.
Un logiciel qui fait de l'argent est un logiciel qui gagne des parts de marché. Plus souvent qu'autrement, l'entreprise qui apporte un logiciel sur le marché premier sera celle qui obtiendra la majorité de la part de marché, même si son logiciel n'est pas le meilleur produit sur son marché particulier .
Par conséquent, l'accent est mis sur la sortie du logiciel plus tôt et imparfait, plutôt que plus tard et parfait.
J'aime la plupart des réponses jusqu'à présent. Voici mon tour là-dessus.
Le coût de l'échec est plus grave pour les voitures que pour les logiciels
Une panne de voiture pourrait potentiellement coûter la 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 qu'une mauvaise sève dans le support de production devra faire des heures supplémentaires. Et si cette personne est un employé exonéré à temps plein, 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 en fait le coût horaire de la main-d'œuvre!
Bien sûr, cela dépend du type de logiciel utilisé (les logiciels qui alimentent les systèmes d'armes, l'avionique ou les systèmes médicaux peuvent également avoir un effet sur la vie), mais une voiture coûte beaucoup d'argent et est utilisée assez régulièrement pour que les lacunes de fiabilité soient assez tangible et douloureux. Les pannes logicielles ont souvent des solutions de contournement.
Une autre pensée: les voitures semblent fiables mais elles ont des coûts de maintenance définis qui sont continus même si la voiture fonctionne bien, et culturellement, cela est accepté et même une fière dépense pour les personnes qui se soucient de leurs véhicules. En revanche, les logiciels sont souvent déjà cassés lors de leur installation et doivent souvent changer avec le temps, mais culturellement, personne ne veut payer pour la maintenance.
Eh bien, les voitures n'étaient pas assez fiables pendant la majeure partie de leur histoire, et il y a certainement une courbe d'apprentissage. Les voitures sont produites à grande échelle depuis environ 60 ans, tandis que les logiciels ne sont produits à grande échelle que depuis environ 20-25. À grande échelle, je veux dire assez grand pour que les masses l'achètent/l'utilisent et il y a vraiment une énorme incitation à comprendre comment perfectionner la procédure pour le créer.
J'aime considérer 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 est largement vérifié pour la compatibilité descendante (ce qui est facile car l'interface est simple). Mais même ainsi, vous avez des problèmes de compatibilité descendante. Les voitures de type "Farrie" ont du mal à rouler sur des routes de type "boue".
Même si votre système d'exploitation, tout comme les routes, nécessite un entretien constant. Jeter les ponts. 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 candidatures seront écrites sur un seul OS. Mais en général, ils doivent exécuter différentes versions de l'OS (différents types de routes). Ainsi, votre application optimisée pour le souper peut fonctionner sans problème et sans problème tant qu'elle est exécutée sur le bon système d'exploitation (autoroutes), tandis que d'autres codes à usage général (plus simples) fonctionneront correctement sur tous les types de routes.
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 OS avec des extensions. Si le gouvernement permettait aux utilisateurs de modifier les routes, il y aurait beaucoup plus d'accidents.
Lorsque vous commencez à limiter la capacité de l'utilisateur à modifier le système d'exploitation, la fiabilité des applications peut devenir presque solide. Regardez tous ces appareils intégrés. Nous ne permettons pas aux utilisateurs de s'approcher de leur système d'exploitation et de fonctionner correctement et en continu 24h/24 et 7j/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é.
C'est une question stupide (pas de votre part, mais de la personne d'origine).
Cela ressemble à mon père (un mécanicien) qui déteste les ordinateurs mais qui 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 (oui, 30+) ordinateurs et aucun d'eux n'a été dans la boutique. Je viens de dépenser 1400 $ pour réparer ma voiture. Allez compter le nombre d'ateliers de réparation automobile vs réparation d'ordinateurs. Encore une fois, stupide analogie.
Les voitures sont en acier, en plastique informatique. 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 été très largement réparés. Montrez-moi une voiture avec des milliers et des milliers d'heures d'utilisation de 26 ans qui fonctionne toujours à 100% de la même manière qu'elle était neuve en usine.
Tout d'abord, votre utilisateur doit savoir qu'il existe un logiciel si fiable dans ce monde qu'il ne sait même pas qu'il existe. Avez-vous déjà vu un crash TV? Moi non plus.
Je pense que la raison principale est que le logiciel est sans importance. Être immatériel signifie que les non-développeurs ne voient pas les progrès en cours. Par exemple, si je fabriquais une voiture, vous pouviez me voir assembler les différentes pièces et cela ressemblerait de plus en plus à une voiture; cependant, si vous me regardez en train de programmer, je vais peut-être passer des heures à maudire un écran noir avec du texte vert faisant des motifs étranges, puis soudainement, lorsque le motif change un peu, je surexcite.
Pour cette raison, 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 tout à fait faux.
De plus, les logiciels sont beaucoup, beaucoup plus souvent fortement personnalisés que les voitures. Lorsque vous personnalisez une voiture, vous n'allez pas à l'encontre de sa conception, car ce serait visiblement stupide. Si mon moteur est à l'avant de la voiture, le déplacer vers l'arrière sera très probablement un énorme désastre. Cependant, comme le logiciel est sans importance, si le client vous demande de faire quelque chose de complètement contre la conception, il n'obtiendra aucune indication (sauf vous, mais il n'écoutera pas) que ce qu'il fait est stupide, puis il ' Je serai tout surpris que cela ne fonctionne pas comme prévu.
- Manque de partage d'informations (les programmeurs volent en solo ou en petits groupes - les concepteurs automobiles travaillent avec des équipes interconnectées au sein d'une grande entreprise, et ils partagent tous leurs connaissances; si nous travaillions tous pour de grandes entreprises, nous serions tous de meilleurs programmeurs grâce à l'apprentissage des autres; c'est aussi pourquoi des choses comme les programmes open source et les ressources en ligne sont très importantes)
- Attentes des participants sur le terrain (ce n'est pas grave si un concepteur automobile n'est que marginalement utile pendant les 5 à 10 premières années, mais si un programmeur se rend dans une interview et dit qu'il/elle ne sera pas très utile pendant 5 à 10 ans, le l'entretien est terminé)
- Manque de tests de pénétration (en raison du manque de fonds, de problèmes de légalité, etc.; les constructeurs automobiles, cependant, claquent voiture après voiture dans un mur de briques, ont des souffleries, ont des exigences de performance relativement simples, etc.)
- Transparence de l'information (vous ne savez pas comment fonctionne la plupart des logiciels; vous devinez ou vous faites des hypothèses basées sur des interviews, des communiqués de presse, de la publicité, etc.; avec des voitures, cependant, la majorité des choses sont là pour vous de regarder)
- Encapsulation inhérente des connaissances (le gars/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 bien informés sur des milliers ou des dizaines de milliers de choses inconnues de la personne moyenne, alors que les concepteurs automobiles uniquement besoin de connaître des centaines ou des milliers)
- Tangibilité (cela aide quand vous pouvez le voir)
- Age of Field (la conception des véhicules a des milliers d'années; la conception des véhicules à moteur a plus de 250 ans [Moteurs à vapeur, etc.])
- Criticité des sous-systèmes (les voitures continueront de "fonctionner" même si beaucoup de leurs pièces cessent de fonctionner - serrures électriques, vitres électriques, CVCA, essuie-glaces, vitres cassées, enjoliveurs perdus, pneus crevés [en mettre un nouveau], radio, une lumière ou deux, une entrée à distance, etc.; quand quelque chose sur un ordinateur tombe en panne, c'est souvent un scénario SHTF)
- Interdépendance (lorsqu'un ordinateur tombe en panne, il n'est pas rare qu'il affecte des centaines ou des milliers d'autres ordinateurs; lorsqu'une voiture tombe en panne, il est assez rare que d'autres voitures soient affectées - si d'autres voitures sont affectées, ce n'est presque toujours que 1) -3)
- Blâme général (si une partie d'un ordinateur ou un ordinateur sur des milliers casse et blesse un système, le blâme s'étend à l'ensemble de l'ordinateur ou, dans ce dernier cas, à l'ensemble du réseau d'ordinateurs; si votre voiture est heurtée par une voiture avec freins défaillants, ou si une voiture cale et ne redémarre pas sur l'autoroute, seule la partie individuelle de la voiture est blâmée)
- Systèmes finis contre infinis (les voitures ne peuvent contenir que beaucoup de choses et elles ne doivent 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 les ordinateurs, cependant, les possibilités sont de facto infinies - il y a toujours de nouvelles choses, de nouvelles API, de nouveaux systèmes d'exploitation, de nouveaux trous de sécurité, des iPads, des logiciels de téléphonie mobile, de nouveaux ceci, de nouveaux, etc.)
- Portée des connaissances requises (une personne avec un QI 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 raison simple pour laquelle toute la logique est défectueuse:
Les dispositifs mécaniques peuvent être simplement réduits à entrée/sortie; l'augmentation du nombre de pièces pour réaliser cette opération d'E/S ne change pas l'opération d'E/S. Ainsi, le système peut être entièrement compris.
Le logiciel d'autre part a Entrée -> Processus -> Sortie. En raison de cette nature, le système ne peut pas être entièrement prévu ou compris.
Donald Rumsfeld l'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 inconnues connues; c'est-à-dire que nous savons qu'il y a des choses que nous ne savons pas. Mais il y a aussi des inconnues inconnues - celles que nous ne savons pas, 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 des inconnus,
- Le logiciel présente les éléments ci-dessus mais également inconnus-inconnus.
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 tout de même fonctionner. Vos freins sont usés ou une valve fuit, mais la voiture fonctionne toujours principalement jusqu'à ce que vous puissiez la faire réparer.
Les logiciels, pour la plupart, n'ont pas de défaillance progressive. Soit ça marche, soit ça casse. La division par zéro n'est pas "presque correcte"; c'est juste une erreur. Lorsque vous essayez d'enregistrer sur un lecteur sans suffisamment d'espace, vous ne pouvez pas presser fort pour forcer toutes les données; ça ne marchera pas.
Je ne pense pas qu'un logiciel soit nécessairement moins fiable qu'une voiture, mais quand un logiciel échoue, il échoue immédiatement, pas progressivement.
Les voitures ne sont pas aussi fiables que vous le pensez. C'est juste que les défauts peuvent rester cachés pendant longtemps (ou ignorés) sans provoquer l'échec de l'ensemble. Votre voiture fuit de l'huile et/ou du liquide de refroidissement? Non? Êtes-vous sûr? Vous avez probablement tort ... Il y a probablement juste une petite fuite quelque part que vous n'avez pas encore remarqué ... Maintenant, étendez cela à la suspension, aux panneaux de carrosserie, à l'intérieur, etc. Je ne pense pas avoir jamais pourtant rencontré une voiture avec laquelle je ne trouvais rien de mal. Cependant, la grande majorité des pièces sont superflues à la mission de transport. Ce n'est pas le cas avec un ordinateur. Presque chaque partie d'un ordinateur est critique.
C'est le vieux débat analogique vs numérique, juste reconditionné. La télévision numérique est géniale, tant que tout est parfait. À l'instant où quelque chose se passe mal, l'audio bégaie et la vidéo se bloque, ce qui le rend inutile. Comparez avec la télévision analogique où vous obtiendrez juste un petit sifflement ou statique qui est facilement ignoré.
Tout d'abord, bien sûr, certains sw sont parfaitement fiables, et les voitures - en particulier britanniques et italiennes - ne sont pas nécessairement aussi fiables.
Cela dit, mon expérience de travail avec les logiciels automobiles se résume à deux choses:
Coûts de garantie. Lorsque votre sw échoue, vous le redémarrez. Vous allez peut-être déposer un rapport de bogue. Ou utilisez le contrat d'assistance coûteux. Lorsque votre voiture tombe en panne, vous l'apporterez et exigerez qu'elle soit réparée sous garantie. Cela coûtera au fabricant 100 $ et plus. Si chaque panne de sw coûtait 2 $ au fabricant, je suis sûr que sw 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'en souciaient vraiment, alors je suis sûr que sw serait plus fiable.
Donc, si vous fabriquez des voitures peu fiables, les coûts de garantie grugeront rapidement tous vos profits et dans quelques années, un classement de mauvaise qualité signifie que vous ne vendrez aucune voiture. Si vous faites un sw peu fiable, les utilisateurs se plaindront et vous vendrez des contrats de support coûteux.
Je ne pense pas que les voitures soient moins complexes. Mais même si c'est le cas, je ne pense pas que les logiciels soient moins fiables. Cependant, je pense qu'il existe des facteurs plus importants qui conduisent à des écarts de fiabilité des logiciels:
Abstraction impliqué dans le logiciel. Cela amène les créateurs de logiciels à mal comprendre comment les choses fonctionnent vraiment. Au fil du temps, de plus en plus d'abstraction est ajoutée. Par exemple, le langage d'assemblage vous donne un contrôle direct sur la machine. C est plus abstrait mais toujours proche de la machine. Java, C # et les prochaines étapes résument fortement ce qui se passe dans la machine. Un autre exemple est que si vous êtes un programmeur qui veut comprendre comment le réseautage se produit au niveau logiciel, alors vous devez savoir programmer avec C car l'infrastructure (en tant que logiciel) est écrite en C.
Différentes expériences et la connaissance des fabricants conduit à des résultats différents. Différents développeurs créent des logiciels avec une fiabilité différente. On peut en dire autant des constructeurs automobiles. Cependant, la différence est que quiconque peut utiliser un éditeur et un compilateur ou même simplement installer un IDE (environnement de développement intégré) peut créer des logiciels et gratuitement. Pour fabriquer une voiture, vous avez besoin 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 d'embaucher les meilleurs dans le domaine . Pourtant, il y a encore des problèmes de fiabilité avec les voitures. Si vous en êtes conscient, plusieurs millions de voitures sont retirées des marchés pour de graves [bugs]. Dans ma voiture, le constructeur remplacera gratuitement les tondeuses de frein pour toutes les voitures achetées. la même année. C'est un problème sérieux et, à mon avis, montre que même les voitures ne sont pas aussi fiables que le dit votre client.
Les bugs dans les 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 prêtons attention à moins de détails comme "La voiture accélère lorsque nous montons sur la pédale d'accélérateur", casse, rotation, lumières, rétroviseurs, etc. Dans le logiciel, à chaque clic/entrée de l'utilisateur, il y a généralement une réponse. Il y a donc de nombreux points où le logiciel peut être bogué et l'utilisateur le remarquera immédiatement. Cela fait croire à l'utilisateur qu'elle est moins fiable que les voitures.
Piratage et attaques. Plus un logiciel est utilisé à grande échelle, plus il sera élevé sous des attaques de piratage. 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 sa destination.
La fiabilité et la sécurité des véhicules automobiles sont obligatoires. Dans de nombreux pays (la plupart?), La loi exige qu'ils aient un niveau minimum de fiabilité et de sécurité et ils sont testés pour le pire des scénarios (quel qu'il soit). Les logiciels commerciaux ne le sont pas, pour la plupart.
Bien qu'il existe d'autres implications juridiques pour les logiciels, il est important de noter que si le logiciel se bloque à chaque fois que vous appuyez sur le bouton "Enregistrer", il s'agit simplement d'un correctif/correctif et vous continuez. Si une voiture se bloque à chaque fois que vous allumez l'indicateur, alors c'est une chose bien pire. Il n'est tout simplement pas si important pour Microsoft Outlook de fonctionner sans se bloquer de façon inattendue que pour un SUV de fonctionner sans se bloquer de manière 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 avions et les systèmes de guidage des missiles doivent être fiables; il y a des vies en jeu! On pourrait espérer que ceux-ci sont testés plus rigoureusement que la voiture à moteur moyenne.
Je pense que j'ai une bien meilleure analogie. Prenez une entreprise qui construit des ambulances selon les spécifications du client. La plate-forme de base (disons, un châssis en coupe de VR entièrement opérationnel et légal pour la rue) nécessite des modifications à plusieurs points: cadre, système de charge, bec de remplissage, suspension, etc. Ces modifications doivent non seulement être légales dans la rue mais également répondre aux exigences juridictionnelles tout en satisfaisant les désirs des clients.
Ensuite, vous devez construire le corps d'ambulance lui-même, qui est également chargé d'exigences réglementaires de plusieurs niveaux de gouvernement et d'autres organismes. Tout en satisfaisant toujours le désir du client pour un arrangement de sièges ou un système de stockage génial. Et n'oubliez pas que vous avez une centaine de clients différents du monde entier, tous sur des calendriers d'achat et de déploiement différents, aucun d'entre eux ne dit jamais "J'en prendrai une douzaine de plus comme le dernier" sans soumettre également des pages d'exceptions qui nécessitent souvent une réingénierie complète de l'ensemble.
Voitures? C'est insignifiant. Vous achetez ce qui est construit et vous n'avez aucun impact direct sur aucun aspect de la conception. Même votre choix de couleur est artificiel car vous ne pouvez pas réellement spécifier quelque chose qui n'a pas déjà été conçu et testé. Dans un certain sens, il n'y a qu'un "marché" et non un "client". Je dirais que les logiciels standard produits pour certains marchés sont généralement aussi fiables que la voiture que vous achetez chez le concessionnaire local.
L'industrie automobile ne met pas une voiture "bêta" à la disposition du public pour des tests, l'industrie automobile n'a pas non plus à se soucier de l'environnement dans lequel elle livre ses produits, mais moi, je dois m'inquiéter de bien d'autres choses. disent que l'industrie du logiciel est d'abord fondamentalement différente (comme nous le savons tous), donc la fiabilité et la complexité sont vraiment suggestives. À mon avis, une voiture aussi complexe qu'un logiciel mais il est plus facile de voir ce qui fonctionne ou non car
- Au fond, les voitures ne sont pas virtuelles, elles seront sûrement plus faciles à tester (mais plus chères)
- Ils ont commencé beaucoup plus tôt que l'industrie du logiciel, même s'ils étaient moins nombreux, vous ne pouvez pas minimiser la pratique et les connaissances qu'ils ont recueillies. L'industrie du logiciel est encore un bébé par rapport à elle.
- Toute l'industrie automobile est tenue par la loi et l'éthique de ne pas fabriquer de voiture qui tue son conducteur, en particulier ces dernières décennies.
Ainsi, la déclaration disant que le logiciel est moins fiable que les voitures, peut être vraie pour de nombreux types de logiciels et complètement fausse pour d'autres domaines (sécurité, aéronautique ...), vous pouvez être sûr qu'un logiciel est au moins le plus fiable que le plus fiable de voitures dans ces zones. Tout simplement parce que ces domaines sont critiques et d'après ce que je sais seulement dans ces domaines, les logiciels peuvent se comparer à l'industrie automobile.
Ce qui nous amène à ceci: la plupart des logiciels ne sont pas considérés comme critiques dans leur domaine. Quand il est considéré comme tel, vous avez un logiciel fiable, le seul problème que vous trouverez sur ceux-ci 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 travaillent 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 livrer le logiciel dès que 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 que vous produisez ce pour quoi vous investissez jamais moins (sauf si vous êtes foutu mais que vous ne produisez rien de tel. ..) et parfois plus ..
Un 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 voiture seraient directement liés à de nombreux autres composants de voiture.
Toutes les voitures du monde égalent à peine le logiciel Unix original en termes de complexité.
C'est comme tout le reste ... quand cela fonctionne, vous vous en fichez ... quand il est cassé (ou ne fonctionne pas comme vous le souhaitez/vous attendez), vous vous en souciez.
Pensez aux avions. Des tonnes de gens s'inquiètent des gens qui tentent de détourner ou de les faire exploser. Mais vraiment, le nombre d'événements négatifs est minime par rapport au nombre de vols quotidiens. (Il y a plus de vols en une journée, puis ils ont déjà été détournés ou bombardés. Diable a 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 (qui se cassent) mais si vous regardez les premières voitures - elles ont cassé un lot.
La `` technologie '' derrière les pièces mécaniques des voitures existe depuis des centaines d'années et le moteur à combustion interne existe également depuis longtemps, et quand ils ont été introduits, il y avait beaucoup de problèmes.
Considérez que les problèmes de mémoire font presque partie du passé avec certaines de nos plateformes gérées. Donnez quelques centaines d'années au logiciel et nous le verrons aussi. En fait, compte tenu de la complexité des logiciels, je pense que nous sommes en avance sur la courbe.
Combien y a-t-il de concepteurs automobiles? 10 000 top? - ils sont talentueux et savent ce qu'ils font.
Combien y a-t-il de programmeurs logiciels? 30 millions? - et beaucoup d'entre eux n'ont aucune idée de ce qu'ils font, prenez par exemple PHP programmeurs, vous pouvez apprendre PHP et écrire votre premier programme en moins de quelques heures.
Si le logiciel ne devait être écrit que par 10 000 des meilleurs programmeurs, il serait aussi fiable que les voitures.
Les voitures modernes comptent sur s/w. Lorsque les voitures modernes échouent, par exemple l'ordinateur du moteur tombe en panne, c'est généralement (mais pas toujours, mais généralement) l'électronique qui l'a détruit, pas le s/w.
Demandez à tout propriétaire d'une voiture moderne avec un ECU dedans combien de temps sa course avant une panne coûteuse. Je serai stupéfait si vous avez 10 ans. Les voitures modernes pleines d'électronique et de capteurs sont incroyablement non fiable.
Si vous étudiez la théorie de la fiabilité, la réponse devient aveuglément évidente. Tout ce qui est mécanique (attendez-vous à un logiciel) a une fiabilité en régime permanent qui est le taux d'échec en dehors des régions de mortalité infantile et d'usure. Le taux de défaillance du produit fini est la somme des taux de défaillance 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 des taux de défaillance de tous ces composants vraiment bas.
Quand il s'agit de choses comme les courroies de distribution et l'usure des cylindres et les capteurs d'oxygène qui se remplissent de merde, et les connecteurs deviennent ohmiques, et les fils se cassent à cause des 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.
Le logiciel, en revanche, a un taux d'échec constant. Malgré la difficulté de trouver parfois des défauts, tous les logiciels sont en fin de compte une machine à saucisses. Entrées -> Faire des choses -> Sorties. Parfois, l'ORDRE des entrées et les combinaisons d'entrées entraînent une défaillance avec des modes détectables. Lorsque cela se produit, vous avez trouvé votre défaut, vous le corrigez et vous continuez.
Un logiciel qui n'a pas de défauts (connus) a effectivement un taux d'échec de 0. Il fonctionnera indéfiniment sans échec. (Temps moyen entre les pannes = 1/taux d'échec). La plate-forme matérielle échouera en premier.
Les logiciels présentant des défauts peuvent s'exécuter uniquement jusqu'à ce que la bonne combinaison de conditions d'entrée, au fil du temps, provoque la manifestation du défaut.
Le FALLACY dans tout cela est d'essayer de comparer les taux de défaillance des choses physiques (causées par l'usure, la migration des métaux dans les circuits intégrés, la pénétration d'eau, les vibrations, etc.) avec un taux de défaillance de ce qui est essentiellement une machine à états finis qui fait simplement exactement ce que sa séquence d'instructions lui dit de faire.
(Même des choses comme des particules alpha renversant des bits dans RAM est un phénomène physique, pas un défaut logiciel. La manière de gérer un tel eveny PEUT cependant être un défaut logiciel, mais rappelez-vous, ce méchant alpha particule était juste une autre entrée dans le logiciel.)
La différence entre le logiciel et les voitures est que, pour que les développeurs de logiciels maintiennent la raison, des doublons exacts du logiciel doivent être générés par tous les utilisateurs du logiciel et pour que les constructeurs automobiles maintiennent la raison, ils doivent accepter que tous leurs utilisateurs conduiront. des voitures sensiblement différentes parce que la façon dont vous conduisez change la voiture, mais la façon dont vous utilisez le 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 elle va échouer.
Si vous aviez un moyen de changer l'huile de votre logiciel, vous seriez probablement en mesure de 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 versions ne changent pas l'huile, elles ressemblent plus à l'ajout d'un allumage sans clé.
Les voitures en panne ne sont pas tolérables. Cela peut également mettre des vies en danger. Les logiciels qui tombent en panne sont tolérés et les utilisateurs peuvent les contourner ou simplement les accepter. Il n'y a pas beaucoup de demande de logiciels sans bug.
Le logiciel a également tendance à être personnalisé, vous n'avez pas 10000000 modèles de voitures différents. Je dirais que wikimedia est fiable et des tonnes de gens utilisent ce logiciel. On pourrait donc dire que beaucoup de gens utilisent des logiciels sans bug ou fiables. (wordpress, divers contrôles de source, mysql et sqlite sont assez fiables, etc.)
Les logiciels sont des objets mathématiques et logiques, tandis que les voitures sont de vrais objets.
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 quelqu'un ayant un problème avec un ordinateur et quelqu'un ayant un problème avec une voiture; 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 beaucoup de lois physiques telles que la thermodynamique, l'électronique, la chimie.
Vous pouvez également extrapoler cette comparaison en disant: "pourquoi un marteau est plus fiable qu'une secrétaire?".
Je ne pense pas que la question soit vraiment pertinente, mais je pense qu'elle montre très bien comment le manque d'une bonne éducation mathématique peut affecter la compréhension d'un certain type de système.