Warum ist Software nicht so zuverlässig wie ein Auto? [geschlossen]

Ich habe diese Frage von einem Benutzer gestellt bekommen. Wir wissen, dass Autos eine Panne haben, aber das liegt an etwas Physischem (es sei denn, es handelt sich um Software!).

Ich habe versucht zu beantworten, dass Software eine viel jüngere Branche ist, aber der Benutzer konterte mit "Ist die Automobilindustrie nicht viel stabiler und zuverlässiger als mit weniger Menschen geworden?".

Ich habe auch versucht zu beantworten, dass Software komplexer ist, aber der Benutzer hat dem widersprochen, dass es viele tausend Teile gibt, aus denen ein Auto besteht. Leute, die Autos konstruieren und bauen, kennen ihre Komponenten im Allgemeinen nur sehr gut, aber sie arbeiten letztendlich doch alle zusammen.

Also, warum ist nicht Software so zuverlässig wie ein Auto?

Die Prämisse Ihrer Frage ist einfach falsch: Software ist nicht "weniger zuverlässig" als ein Auto. Es gibt Milliarden von Geräten, auf denen Embedded-Software jahrelang rund um die Uhr ohne Probleme ausgeführt wird. Zum Teufel, einige davon sind in Autos und steuern / überwachen den Motor. Wie kann Software also weniger zuverlässig sein als ein Auto, wenn Autos selbst auf Software angewiesen sind?

Ich entwerfe Software und mechanische Teile.

Es ist Komplexität.

Denn in moderner Software stecken Millionen von "Teilen".

Software-Teile sind sehr kompliziert und haben viel STATE. Ein mechanisch unbewegliches Teil hat keinen Zustand.

Ein mechanisch bewegliches Teil hat seine Position (eine Variable).

Ein Programm, das ausgeführt wird und 1 MB RAM verwendet, verfügt über einen Status von einer Million Byte. Das ist weit mehr Zustand als jedes normale mechanische System.

Es wird eine Kombination von Zuständen geben, die niemals getestet werden, weil sie so selten auftreten. In einem mechanischen System (wie einem Auto) ist es einfach zu überprüfen, dass sich mechanische Teile während des Betriebs nicht berühren. Die mechanische CAD-Software, die ich bei der Arbeit verwende, erledigt dies automatisch.

Wenn Sie Maschinen aus unsichtbaren, nicht berührbaren Teilen bauten und Millionen beweglicher Teile hatten, die sich alle nur verfehlten, wäre das wie ein einfaches Programm.

Sogar "Hallo Welt" läuft auf einem Betriebssystem. Die alten 8-Bit-Systeme und Minicomputer-Betriebssysteme waren ziemlich zuverlässig, weil sie einfach waren.

Dinge wie DLLs und gemeinsam genutzte Bibliotheken werden im Rahmen von Virenupdates oder Softwareinstallationen ersetzt, und das Programm von Interesse funktioniert dann nicht. Ein bisschen wie das Austauschen des Reifens an Ihrem Auto gegen einen Fahrradreifen. Einige der Randzustände der Bibliotheksfunktion stören sich (verhalten Sie sich nicht so, wie das Programm es erwartet).

In Sprachen wie Java geschriebene Programme, die viele nicht entworfene Interaktionen zwischen Objekten (Wiederverwendung von Zeigern, Überläufe von Array-Grenzen) nicht zulassen, sind im Allgemeinen ziemlich zuverlässig, wenn Sie sie erst einmal zum Laufen bringen.
Wenn Sie Betriebssysteme mit statischen Bibliotheken verwenden, funktioniert ein Programm, sobald es funktioniert, einfach weiter (es weist jedoch immer noch viele Randbedingungen auf, basierend auf seiner Zustandsgröße).

Dave Parnas schreibt über die Zuverlässigkeit von Software, indem er den Status des Programms verkleinert. Die strengen Funktionsprogrammierer machen dasselbe, indem sie eine einzelne statische Zuweisung erzwingen.

Es ist eine Frage der Wahl des Verbrauchers.

Wenn die Verbraucher forderten, dass Software so zuverlässig ist wie mein Honda Civic (im Gegensatz zu meinem alten Ford Maverick), wäre dies der Fall. Einige Unternehmen fordern Software, die zuverlässig ist, und sie erhalten sie, normalerweise für eingebettete Software, manchmal für sicherheitskritische Dinge wie Weltraummissionen und Flugsicherung. Die Software ist immer noch nicht perfekt, aber auch keine Autos.

Kunden fordern jedoch andere Eigenschaften ihrer Software und sind meistens nicht bereit, für Software zu zahlen, die möglicherweise weniger funktionsfähig ist, mit Sicherheit teurer und später geliefert wird, nur weil sie zuverlässiger ist.

Es gibt viele tausend Teile, aus denen ein Auto besteht.

Wenn nur ein Computer (und die dazugehörige Software) so einfach wäre.

Der Computer hat was ein Gigabyte Speicher? Milliarden von Flip-Flops? Ein Terabyte Festplatte? Billionen "bewegter" Teile?

In der Software können Zehntausende oder Hunderttausende einzelner Codezeilen ausgeführt werden. Plus, dass viele (oder mehr) in Unit-Tests und Tools.

Nein. Das Argument "Autos sind auch komplex" ist schlecht. Software ist viel, viel, viel komplexer als ein Auto.

Die Prinzipien, nach denen Verbrennungsmotoren funktionieren, und alle Komponenten, aus denen ein Auto besteht, haben sich im vergangenen Jahrhundert kaum verändert. Sicher, es gab evolutionäre Verbesserungen und Hybridautos, aber die grundlegenden Komponenten sind dieselben. Sie haben einen Motor, einen Antriebsstrang usw. Auch Concept Cars und Ihr superteuerer, extrem schneller Bugatti Veyron haben die gleiche Grundstruktur. Kurz gesagt, das Entwerfen eines Autos ist ein bekanntes Problem .

Vergleichen Sie dies mit der Entwicklung von Software.

• Kunden wissen nicht, was sie wollen, wenn sie anfangen. Sie fangen an, über einen Luxusjet zu sprechen, aber wenn sie die Kosten erkennen, möchten sie, dass Sie ihn für die Kosten eines Scooters mit Fußantrieb bauen.
• Das Autodesign benötigt Jahre, um von der Idee zum Konzeptauto zu gelangen, und weitere Jahre, um von dort zur Herstellung zu gelangen. Wann hatten Sie das letzte Mal diesen Luxus mit Software?
• Autoteile sind gegossene Metallteile, aber Softwarekomponenten können häufig ihre Form und Schnittstelle ändern.
• Der Herstellungsprozess ist völlig anders. Bei Autos werden die Teile in Massen hergestellt und die gleichen Teile werden für verschiedene Fahrzeuge verwendet. Mit Software wird fast alles von Hand gefertigt, da sonst Dinge einfach nicht passen.

Kurz gesagt, es gibt eine Reihe von Gründen, warum ein Auto als "zuverlässiger" als Software wahrgenommen wird. Ich habe mir gerade ein paar ausgedacht.

Autos sind zuverlässig. So ist die meiste Software.

Aber ... Custom Cars und Custom Software haben beide ihre Probleme.

Jeder echte Auto-Enthusiast, der sein 1970 modifiziertes Muscle-Car hat, bastelt und dreht und Pannen hat, und alle möglichen dummen Probleme, die er nicht gehabt hätte, wenn er es original belassen hätte. Aber ... dann hätte er den Kompressor nicht ...

Da das Auto, das Sie fahren, viele Male hergestellt wurde, wurde der Konstruktionsprozess so verfeinert, dass dasselbe Auto immer wieder in einer Produktionslinie hergestellt werden kann.

Wenn es sich um ein einzigartiges, komplexes, von Grund auf neu gebautes Auto handeln würde, wäre es bei weitem nicht so zuverlässig. Schauen Sie sich zum Beispiel an, wie viel höher die Ausfallrate in Formel-1-Rennwagen ist. Es ist üblich, dass ein oder zwei pro Rennen ausfallen.

Neue Software ist immer ein Unikat. Was der Programmierer Code wurde noch nie von ihnen codiert. Um in diesem Szenario eine wirklich hohe Qualität zu erzielen, sind die Kosten für die meisten Produkte unerschwinglich. Jede nicht triviale neue Software ist quasi ein Prototyp.

Abgesehen davon ist dies einer der Hauptgründe dafür, dass die Anwendung traditioneller Engineering-Techniken auf das Software-Engineering eine Katastrophe darstellt.

1. Autohersteller erhalten die gesamte Spezifikation festgenagelt, bevor sie das "Endprodukt" produzieren.
2. Automobilnutzer neigen nicht dazu, dumme Dinge zu tun, die die Designer nicht erwartet hatten.
3. Autos werden (normalerweise) nur einmal pro Jahr "aktualisiert", wohingegen erwartet wird, dass die meiste Software mehrmals pro Jahr aktualisiert wird.

Ich könnte weitermachen, aber mein Browser fühlt sich an, als würde er abstürzen ...

Es gibt tatsächlich einen sehr einfachen Grund.

Software, die Geld verdient, ist Software, die Marktanteile gewinnt. Mehr als oft nicht, das Unternehmen , das ein Stück Software auf den Markt bringt erstes wird derjenige sein, der die Mehrheit des Marktanteils bekommt, auch wenn ihre Software nicht das beste Produkt in ihrem jeweiligen Markt.

Infolgedessen liegt der Fokus darauf, Software eher früher und unvollkommener als später und perfekter herauszubringen.

Die meisten Antworten gefallen mir bisher. Hier ist mein Dreh.

Die Kosten für ein Versagen sind für Autos schwerwiegender als für Software

Ein Versagen des Autos könnte möglicherweise ein Leben kosten. Selbst ein nicht lebensbedrohlicher Fahrzeugausfall ist für den Benutzer unübersehbar. Ein Softwarefehler bedeutet nur, dass ein Teil des unzureichenden Produktionssupports Überstunden leisten muss. Und wenn diese Person ein ganztägig freigestellter Angestellter ist, dann ist es gar nicht so teuer. In der Tat werden schlechte Qualität und schlechtes Management belohnt, weil freie Überstunden tatsächlich die Arbeitskosten pro Stunde senken!

Dies hängt natürlich von der Art der verwendeten Software ab (Software, die Waffensysteme, Avionik oder medizinische Systeme antreibt, könnte sich auch auf das Leben auswirken), aber ein Auto kostet eine Menge Geld und wird regelmäßig so oft verwendet, dass die Zuverlässigkeit sinkt ganz greifbar und schmerzhaft. Bei Softwarefehlern treten häufig Problemumgehungen auf.

Ein anderer Gedanke: Autos scheinen zuverlässig zu sein, aber sie haben definitiv laufende Wartungskosten, auch wenn das Auto gut funktioniert, und dies wird kulturell akzeptiert und ist sogar eine stolze Ausgabe von Menschen, die sich um ihre Fahrzeuge kümmern. Software dagegen ist oft schon bei der Installation kaputt und muss sich im Laufe der Zeit ändern, aber kulturell will niemand für die Wartung bezahlen.

Nun, Autos waren für den größten Teil ihrer Geschichte ziemlich unzuverlässig, und es gibt definitiv eine Lernkurve. Autos werden seit ungefähr 60 Jahren in großem Maßstab hergestellt, während Software nur für ungefähr 20-25 Jahre in großem Maßstab hergestellt wird. Mit "groß" meine ich im Grunde genommen "groß genug", dass die Massen es kaufen / verwenden, und es gibt wirklich einen enormen Anreiz, herauszufinden, wie das Verfahren zu seiner Erstellung perfektioniert werden kann.

Ich stelle mir das Auto gerne als eine Anwendung vor. Während das Betriebssystem die Straße ist, auf der die Anwendung ausgeführt wird.

Die Schnittstelle zwischen Straße und Auto ist gut definiert. Gut getestet und wird ausführlich auf Abwärtskompatibilität geprüft (was einfach ist, da die Benutzeroberfläche einfach ist). Trotzdem haben Sie einige Probleme mit der Abwärtskompatibilität. Autos vom Typ "Farrie" haben es schwer, auf Straßen vom Typ "Schlammstraßen" zu fahren.

Auch wenn Ihr Betriebssystem genau wie Straßen ständig gewartet werden muss. Brücken waren raus. Autos ziehen Schneeketten an und reißen die Straßen auf, als ob Anwendungen beschädigt und die vom Betriebssystem verwendeten Datenträger und Dateien beschädigt würden.

Anwendungen werden auf einem Betriebssystem geschrieben. Im Allgemeinen müssen sie jedoch unterschiedliche Versionen des Betriebssystems ausführen (unterschiedliche Straßentypen). So läuft Ihre für das Abendessen optimierte App möglicherweise reibungslos und ohne Probleme, solange sie auf dem richtigen Betriebssystem (Highways) ausgeführt wird, während Code für andere allgemeine Zwecke (einfacher) auf allen Straßentypen problemlos ausgeführt werden kann.

Die Schnittstelle zwischen Anwendung und Betriebssystem ist definiert, aber äußerst komplex und schwankt immer leicht. Zumal wir dem Benutzer erlauben, sein eigenes Betriebssystem mit Erweiterungen zu modifizieren. Wenn die Regierung den Benutzern erlaubt, die Straßen zu ändern, würde es viel mehr Unfälle geben.

Wenn Sie anfangen, die Möglichkeiten des Benutzers zum Ändern des Betriebssystems einzuschränken, kann die Zuverlässigkeit der Anwendungen nahezu unerschütterlich werden. Schauen Sie sich all diese eingebetteten Geräte an. Wir lassen Benutzer nicht in die Nähe ihres Betriebssystems und Ihr System läuft rund um die Uhr ohne Unterbrechung.

Also ich würde sagen, es ist nicht so, dass Software unzuverlässig ist. Es ist eher so, als würde man sagen, dass der Benutzer Löcher für die Anwendungen in die Autobahn gräbt. Hey, deine Bewerbung ist gerade in das Loch gefallen, das ich letztes Jahr gegraben und vergessen habe .

Zunächst muss Ihr Benutzer wissen, dass es auf dieser Welt Software gibt, die so zuverlässig ist, dass er nicht einmal weiß, dass sie existiert. Haben Sie jemals einen TV-Absturz gesehen? Ich auch nicht.

Ich denke, der Hauptgrund ist, dass Software unerheblich ist. Immateriell zu sein bedeutet, dass Nicht-Entwickler den Fortschritt nicht sehen. Wenn ich zum Beispiel ein Auto baue, sehe ich, wie ich die verschiedenen Teile zusammenbaue, und es sieht immer mehr aus wie ein Auto. Wenn Sie mich jedoch beim Programmieren ansehen, verbringe ich möglicherweise Stunden damit, auf einem schwarzen Bildschirm mit grünem Text seltsame Muster zu fluchen. Wenn sich das Muster dann plötzlich ein wenig ändert, bin ich überfordert.

Aus diesem Grund erkennen normale Menschen die Komplexität von Software nicht. Wenn sie ein Fenster sehen, denken sie, dass sie das Programm als Ganzes sehen, was ach so falsch ist.

Außerdem wird Software sehr viel häufiger angepasst als Autos. Wenn Sie ein Auto anpassen, werden Sie nicht gegen sein Design verstoßen, weil das sichtlich dumm wäre. Wenn sich mein Motor vorne im Auto befindet, wird es höchstwahrscheinlich eine große Katastrophe sein, ihn nach hinten zu bewegen. Da Software jedoch unerheblich ist, wird der Kunde, wenn er Sie auffordert, etwas gegen das Design zu unternehmen, keinen Hinweis erhalten (außer Ihnen, aber er hört nicht zu), dass das, was er tut, dumm ist. Ich werde mich wundern, dass es nicht wie erwartet funktioniert.

1. Mangelnder Informationsaustausch (Programmierer fliegen alleine oder in kleinen Gruppen - Autodesigner arbeiten mit miteinander verbundenen Teams in einem großen Unternehmen und sie alle teilen ihr Wissen. Wenn wir alle für große Unternehmen arbeiten, sind wir alle aufgrund des Lernens bessere Programmierer von anderen, auch deshalb sind Dinge wie Open-Source-Programme und Online-Ressourcen sehr wichtig)
2. Erwartungen an Feldeinsteiger (es ist in Ordnung, wenn ein Autodesigner in den ersten 5 bis 10 Jahren nur geringfügig von Nutzen ist, ein Programmierer jedoch in ein Interview geht und angibt, dass er / sie für 5 bis 10 Jahre nicht viel nützt) Interview ist vorbei)
3. Fehlende Durchdringungstests (aufgrund von Geldmangel, Legalitätsproblemen usw.; Autohersteller schlagen jedoch Auto für Auto gegen eine Mauer, haben Windkanäle, stellen relativ einfache Leistungsanforderungen usw.)
4. Informationstransparenz (Sie wissen nicht, wie die meisten Software-Programme funktionieren; Sie raten oder treffen Annahmen, die auf Interviews, Pressemitteilungen, Werbung usw. beruhen. Bei Autos ist der Großteil der Dinge jedoch genau dort, wo Sie sie sich ansehen können.)
5. Inhärente Verkapselung von Wissen (der Typ / Roboter, der den Rahmen zusammenschweißt, muss die Mathematik hinter dem Stabilitätskontrollsystem nicht kennen; Programmierer müssen über Tausende oder Zehntausende von Dingen Bescheid wissen, die dem Durchschnittsmenschen unbekannt sind, wohingegen Autodesigner nur müssen hunderte oder tausende wissen)
6. Greifbarkeit (es hilft, wenn Sie es sehen können)
7. Age of Field (Fahrzeugdesign ist Tausende von Jahren alt; motorisiertes Fahrzeugdesign ist über 250 Jahre alt [Dampfmaschinen usw.])
8. Kritikalität von Subsystemen (Autos werden immer noch "funktionieren", auch wenn viele ihrer Teile nicht mehr funktionieren - elektrische Schlösser, elektrische Fensterheber, Klimaanlage, Scheibenwischer, zerbrochene Scheiben, verlorene Radkappen, platte Reifen, Radio, ein oder zwei Ampeln, Fernzugriff usw .; wenn etwas an einem Computer kaputt geht, ist dies oft ein SHTF-Szenario.)
9. Interdependenz (wenn ein Computer ausfällt, sind nicht selten Hunderte oder Tausende anderer Computer betroffen; wenn ein Auto ausfällt, sind andere Autos eher selten betroffen - wenn andere Autos betroffen sind, sind es fast immer nur 1 -3)
10. Blanket Blame (Wenn ein Teil eines Computers oder ein Computer von Tausenden ein System kaputt macht und verletzt, erstreckt sich die Schuld auf den gesamten Computer oder im letzteren Fall auf das gesamte Computernetzwerk; wenn Ihr Auto von einem Auto mit einem Defekt getroffen wird) ausgefallene Bremsen oder wenn ein Auto stehen bleibt und nicht auf der Autobahn neu startet, wird nur das einzelne Autoteil dafür verantwortlich gemacht)
11. Finite vs. Infinite-Systeme (Autos können nur so viel Platz haben, und es wird erwartet, dass sie nur unter eingeschränkten Bedingungen funktionieren - z. B. Sie fahren keinen BMW über Gelände, das nur ein Jeep-ähnliches Fahrzeug kann; mit Computern, Die Möglichkeiten sind jedoch de facto unbegrenzt - es gibt ständig neue Dinge, neue APIs, neue Betriebssysteme, neue Sicherheitslücken, iPads, Handysoftware, neue dies, neu das usw.)
12. Umfang der erforderlichen Kenntnisse (eine Person mit einem IQ von 130-140 kann fast alles über Autos lernen, aber nur einen Bruchteil dessen, was es über Computer und Programmierung zu wissen gibt)

Der einfache Grund, warum die gesamte Logik fehlerhaft ist:

Mechanische Geräte können einfach auf Input / Output reduziert werden . Durch Erhöhen der Anzahl der Teile, um diese E / A-Operation zu erreichen, wird die E / A-Operation nicht geändert. Somit kann das System vollständig verstanden werden.

Software hingegen hat Input -> Process -> Output . Aufgrund dieser Natur kann das System nicht vollständig vorhergesagt oder verstanden werden.

Donald Rumsfeld sagte es am besten:

„Es gibt bekannte Bekannte; Es gibt Dinge, von denen wir wissen, dass wir sie kennen. Wir wissen auch, dass es bekannte Unbekannte gibt; Das heißt, wir wissen, dass es einige Dinge gibt, die wir nicht wissen. Es gibt aber auch unbekannte Unbekannte, die wir nicht kennen, die wir nicht kennen. - US-Verteidigungsminister Donald Rumsfeld

In Summe:

• Ein mechanisches Gerät ist ein System, das bekannte und bekannte Unbekannte hat,
• Software hat die oben genannten aber auch Unbekannten-Unbekannten.

Dies ist eine blöde Frage (nicht von Ihnen, sondern von der ursprünglichen Person).

Das klingt wie mein Vater (ein Mechaniker), der Computer hasst und dennoch den ganzen Tag bei eBay verbringt.

Es ist wie die Frage "Warum ist ein Baum zuverlässiger als eine Motte?".

Zuallererst besitze ich 30 (ja, 30+) Computer und keiner von ihnen war im Laden. Ich habe gerade 1400 Dollar für mein Auto ausgegeben, um es zu reparieren. Zählen Sie die Anzahl der Autowerkstätten im Vergleich zur Computerreparatur. Nochmals dumme Analogie.

Autos sind aus Stahl, Computer aus Kunststoff. Autos funktionieren bei jedem Wetter, Computer für den Innenbereich.

Mein Commodore 64 (26 Jahre) funktioniert einwandfrei und wurde nicht repariert. Beide meiner Fahrzeuge (jünger als 10 Jahre) wurden sehr umfangreich repariert. Zeigen Sie mir ein Auto mit Tausenden und Abertausenden von Betriebsstunden, das 26 Jahre alt ist und das immer noch zu 100% so läuft wie damals, als es fabrikneu war.

Software basiert auf Bits: 0 und 1. Autos basieren (meistens) auf mechanischen Teilen.

Ein mechanisches Teil kann abgenutzt sein oder eine Fehlfunktion aufweisen und dennoch arbeiten. Ihre Bremsen sind verschlissen oder ein Ventil ist undicht, aber das Auto funktioniert meistens noch, bis Sie es reparieren lassen können.

Software hat größtenteils nichts mit allmählichem Versagen zu tun. Entweder funktioniert es oder es geht kaputt. Teilen durch Null ist nicht "fast richtig"; Es ist nur ein Fehler. Wenn Sie versuchen, auf einem Laufwerk zu speichern, auf dem nicht genügend Speicherplatz vorhanden ist, können Sie nicht allzu viel Druck ausüben, um alle Daten zu speichern. es geht einfach nicht.

Ich denke nicht, dass Software notwendigerweise weniger zuverlässig ist als ein Auto, aber wenn Software versagt, versagt sie sofort, nicht allmählich.

Ich denke, ich habe eine viel bessere Analogie. Nehmen Sie eine Firma, die Krankenwagen nach Kundenspezifikation baut. Die Basisplattform (z. B. ein voll funktionsfähiges und straßenzulässiges RV-Cutaway-Chassis) erfordert Änderungen an mehreren Punkten: Rahmen, Ladesystem, Einfüllstutzen, Aufhängung usw. Diese Änderungen müssen nicht nur straßenzulässig sein, sondern auch den gesetzlichen Anforderungen entsprechen bei der Erfüllung von Kundenwünschen.

Dann müssen Sie die Ambulanz selbst bauen, die auch von mehreren Regierungsebenen und anderen Stellen mit regulatorischen Anforderungen behaftet ist. Während immer noch den Kundenwunsch nach einer flippigen Sitzanordnung oder einem Aufbewahrungssystem befriedigt wird. Und vergessen Sie nicht, dass Sie hundert verschiedene Kunden aus der ganzen Welt haben, die alle unterschiedliche Einkaufs- und Bereitstellungspläne haben. Keiner von ihnen sagt jemals "Ich nehme ein Dutzend genauso wie der letzte", ohne auch Seiten mit Ausnahmen einzureichen erfordern häufig eine vollständige Überarbeitung des Ganzen.

Autos? Das ist trivial. Sie kaufen, was gebaut wurde und Sie haben keinen direkten Einfluss auf irgendeinen Aspekt des Designs. Sogar Ihre Wahl der Farbe ist künstlich, weil Sie nicht wirklich etwas spezifizieren können, das nicht bereits ausgeführt und geprüft worden ist. In gewisser Weise gibt es nur einen "Markt", keinen "Kunden". Ich würde argumentieren, dass für einige Märkte produzierte Standard-Software im Allgemeinen genauso zuverlässig ist wie das Auto, das Sie beim örtlichen Händler abholen.

Autos sind nicht so zuverlässig, wie Sie denken. Es ist nur so, dass Fehler für eine lange Zeit verborgen bleiben (oder ignoriert werden) können, ohne dass das Ganze versagt. Ihr Auto läuft Öl und / oder Kühlmittel aus? Nein? Bist du sicher? Wahrscheinlich irren Sie sich ... Wahrscheinlich tritt nur eine sehr kleine Menge aus, die Sie noch nicht bemerkt haben bin noch auf ein Auto gestoßen, mit dem ich nichts falsch machen konnte. Die überwiegende Mehrheit der Teile ist jedoch für den Transport überflüssig. Nicht so bei einem Computer. Nahezu jedes Teil eines Computers ist kritisch.

Es ist die alte analoge vs. digitale Debatte, die nur neu verpackt wurde. Digitales Fernsehen ist großartig, solange alles perfekt ist. In dem Moment, in dem etwas schief geht, ruckelt der Ton und das Video blockiert, wodurch es unbrauchbar wird. Vergleichen Sie mit analogem Fernsehen, bei dem Sie nur ein leichtes Rauschen oder eine statische Aufladung hören, die Sie leicht ignorieren können.

Erstens ist ein gewisser SW natürlich absolut zuverlässig, und Autos - insbesondere britische und italienische - sind nicht unbedingt so zuverlässig.

Aus meiner Erfahrung mit Automotive-Software geht hervor, dass es sich um zwei Dinge handelt:

• Garantiekosten. Wenn Ihr SW ausfällt, starten Sie es neu. Vielleicht werden Sie einen Fehlerbericht einreichen. Oder nutzen Sie den teuren Supportvertrag. Wenn Ihr Auto ausfällt, bringen Sie es mit und fordern, dass es im Rahmen der Garantie repariert wird. Dies kostet den Hersteller 100 USD und mehr. Wenn jeder SW-Fehler den Hersteller $ 2 kosten würde, wäre SW mit Sicherheit zuverlässiger.

• JD Powers (und andere Qualitätsklassifizierungen). JD Powers befragt ThingsGoneWrong (das kann alles sein). Und wenn dieses Ranking wirklich schlecht ist, werden die Leute Ihr Auto einfach nicht kaufen, zumindest nicht für genug Geld, um einen Gewinn zu erzielen. Wenn wir eine JD Powers für sw hätten und die Leute sich wirklich darum kümmern würden, dann wäre sw sicher zuverlässiger.

Wenn Sie also unzuverlässige Autos herstellen, gehen die Garantiekosten schnell zu Ende und in ein paar Jahren bedeutet eine schlechte Qualität, dass Sie überhaupt keine Autos mehr verkaufen. Wenn Sie einen unzuverlässigen SW erstellen, beschweren sich die Benutzer und Sie können teure Supportverträge verkaufen.

Die Zuverlässigkeit und Sicherheit von Kraftfahrzeugen ist vorgeschrieben. In vielen (den meisten?) Ländern ist es gesetzlich vorgeschrieben, dass sie ein Mindestmaß an Zuverlässigkeit und Sicherheit aufweisen und auf das Worst-Case-Szenario getestet werden (was auch immer das ist). Kommerzielle Software ist zum größten Teil nicht.

Es gibt zwar andere rechtliche Auswirkungen auf die Software, es ist jedoch wichtig zu beachten, dass wenn die Software jedes Mal abstürzt, wenn Sie auf die Schaltfläche "Speichern" klicken, dies lediglich ein Patch / Fix ist und Sie weitermachen. Wenn ein Auto jedes Mal, wenn Sie die Anzeige einschalten, abstürzt, ist dies eine viel schlimmere Sache. Es ist einfach nicht so wichtig, dass Microsoft Outlook ohne unerwartete Abstürze ausgeführt wird, sondern dass ein SUV ohne unerwartete Abstürze ausgeführt wird.

Davon abgesehen gibt es andere Softwareteile, die genauso viel oder mehr Verantwortung tragen als die Mechanik eines Autos. Flugzeuge und Raketenleitsysteme müssen zuverlässig sein. Es stehen Leben auf dem Spiel! Man würde hoffen, dass diese strenger als das durchschnittliche Auto getestet werden.

Die Autoindustrie gibt kein Beta-Auto zum Testen für die Öffentlichkeit frei, die Autoindustrie muss sich auch keine Sorgen um das Umfeld machen, in dem sie ihre Produkte ausliefert, aber ich muss mich um viele andere Dinge kümmern sagen, dass die Software-Industrie zunächst grundlegend anders ist (wie wir alle wissen), so dass Zuverlässigkeit und Komplexität wirklich suggestiv sind. Meiner Meinung nach ist ein Auto so komplex wie eine Software, aber es ist einfacher zu sehen, was seitdem funktioniert oder nicht

• Am Ende sind Autos nicht virtuell, es muss einfacher zu testen sein (aber teurer)
• Sie haben viel früher als die Softwareindustrie angefangen, auch wenn es weniger Leute waren, kann man die gesammelten Praktiken und Kenntnisse nicht minimieren. Die Softwareindustrie ist immer noch ein Baby im Vergleich dazu.
• Die gesamte Autoindustrie ist gesetzlich und ethisch verpflichtet, kein Auto zu bauen, das ihren Fahrer umbringt, insbesondere in den letzten Jahrzehnten.

Die Aussage, dass Software weniger zuverlässig als Autos ist, kann für viele Arten von Software zutreffen und für andere Bereiche (Sicherheit, Luftfahrt ...) völlig falsch sein. Sie können also sicher sein, dass eine Software mindestens am zuverlässigsten als am zuverlässigsten ist von Autos in diesem Bereich. Einfach, weil diese Bereiche kritisch sind und von dem, was ich nur in diesen Bereichen weiß, Software mit der Autoindustrie vergleichen kann.

Das führt uns dazu: Die meisten Software-Produkte werden in ihrem Bereich als nicht kritisch eingestuft. Wenn es als solches betrachtet wird, haben Sie zuverlässige Software. Das einzige Problem, das Sie dabei finden, sind Probleme, die mit der Umgebung zusammenhängen (wenn Sie es also kontrollieren können, haben Sie praktisch kein Problem), nicht die Software selbst. Die meisten Software-Editoren arbeiten jedoch nicht in diesem kritischen Bereich. Natürlich sind sie verpflichtet, ein bestimmtes Qualitätsniveau bereitzustellen, aber sie sind (meiner Meinung nach) eher verpflichtet, die Software so schnell wie möglich bereitzustellen. Gute Software erfordert jedoch: gutes Projektmanagement, solide Spezifikationen, gutes Design und gute Kenntnisse der Mitarbeiter (um sie wieder aufzunehmen). Das ist nur, um es zu machen, wir reden nicht einmal darüber, es zu verkaufen ...

All dies braucht Zeit und erfordert Geld. Ich sage nicht, dass Sie das bekommen, wofür Sie bezahlen, was ich sage. Die meiste Zeit produzieren Sie, wofür Sie investieren, niemals weniger (es sei denn, Sie wurden verarscht, aber dann produzieren Sie nichts ...) und manchmal mehr. .

Ich glaube nicht, dass Autos weniger komplex sind. Aber selbst wenn dies der Fall ist, halte ich Software nicht für weniger zuverlässig. Ich glaube jedoch, dass es wichtigere Faktoren gibt, die zu Unstimmigkeiten bei der Zuverlässigkeit von Software führen:

1. Abstraktion in Software beteiligt. Dies führt dazu, dass Software-Entwickler falsch verstehen, wie die Dinge wirklich funktionieren. Mit der Zeit kommt immer mehr Abstraktion hinzu. Mit der Assemblersprache können Sie beispielsweise direkt auf die Maschine zugreifen. C ist abstrakter, aber immer noch in der Nähe der Maschine. Java, C # und was als nächstes kommt, abstrahieren stark, was in der Maschine passiert. Ein anderes Beispiel ist, wenn Sie ein Programmierer sind, der verstehen möchte, wie Netzwerke auf Software-Ebene auftreten, dass Sie mit C programmieren sollten, da die Infrastruktur (als Software) in C geschrieben ist.

2. Unterschiedliche Erfahrungenund Kenntnis der Macher führt zu unterschiedlichen Ergebnissen. Verschiedene Entwickler erstellen Software mit unterschiedlicher Zuverlässigkeit. Gleiches gilt für Autohersteller. Der Unterschied besteht jedoch darin, dass jeder, der einen Editor und einen Compiler verwenden oder einfach eine IDE (Integrated Development Environment) installieren kann, Software erstellen kann und dies kostenlos. Um ein Auto zu bauen, braucht man eine riesige Investition, eine Fabrik (manche können ein Auto ohne Verwendung herstellen, aber Sie werden es nicht überall in Ihrer Nähe finden). Die Tatsache, dass Sie eine enorme Investition tätigen, bedeutet, dass Sie versuchen, die Besten auf dem Gebiet einzustellen. Es gibt jedoch immer noch Zuverlässigkeitsprobleme mit Autos. Wenn Sie sich dessen bewusst sind, werden viele Millionen Autos wegen schwerwiegender [Fehler] vom Markt genommen. In meinem Auto ersetzt der Hersteller die Bremsschere kostenlos für alle Autos, die im selben Jahr gekauft wurden.

3. Fehler in der Software treten bei Benutzern normalerweise häufiger auf als bei Autos. Dies ist das Ergebnis von Interaktivität und Reaktion zwischen dem Benutzer und der Software. In einem Auto achten wir auf weniger Details wie "Das Auto beschleunigt, wenn wir auf das Gaspedal treten", Bremsen, Drehen, Licht, Spiegel usw. In der Software gibt es normalerweise bei jedem Benutzer einen Klick / eine Eingabe eine Antwort. Es gibt also viele Punkte, an denen die Software fehlerhaft sein kann und der Benutzer es sofort bemerkt. Dies lässt einen Benutzer glauben, dass es weniger zuverlässig ist als Autos.

4. Hacking und Angriffe . Je häufiger eine Software verwendet wird, desto höher ist der Prozentsatz der Hacking-Angriffe. Sie können dies mit Autodiebstahl vergleichen. Für mich ist die Zuverlässigkeit eines Autos auch dann gefährdet, wenn es von einer anderen Person als seinem Besitzer oder Schlüssel geöffnet werden kann. Es ist jedoch einfacher, Software anzugreifen als ein Auto, da der Angreifer nicht sichtbar ist. Wenn also eine Software kompromittiert wird, erklären die Leute, dass sie nicht zuverlässig ist, obwohl sie zuverlässig ist, wofür sie gemacht wurde.

Es ist wie alles andere ... wenn es funktioniert ist es dir egal ... wenn es kaputt ist (oder nicht so funktioniert, wie du es willst / erwartest), ist es dir egal.

Denken Sie an Flugzeuge. Unmengen von Menschen sorgen sich um Menschen, die versuchen, sie zu entführen oder in die Luft zu jagen. Aber wirklich ist die Anzahl der negativen Ereignisse im Vergleich zur Anzahl der täglichen Flüge winzig. (Es gibt mehr Flüge an einem Tag als jemals zuvor entführt oder bombardiert worden sind. Ich habe sogar versucht, entführt oder bombardiert zu werden.)

Alles hängt davon ab, wie Sie aussehen und wie Sie messen.

Es ist eigentlich ganz einfach. Autos sind alte Technik. Klar, es gibt heutzutage Schnickschnack (diese Pause), aber wenn man sich frühe Autos ansieht - sie haben viel kaputt gemacht .

Die "Technologie" hinter den mechanischen Teilen von Autos gibt es schon seit Hunderten von Jahren, und der Verbrennungsmotor gibt es schon seit langer Zeit, und als sie eingeführt wurden, gab es viele Probleme.

Bedenken Sie, dass Speicherprobleme mit einigen unserer verwalteten Plattformen fast der Vergangenheit angehören. Geben Sie der Software ein paar hundert Jahre Zeit und wir werden sie auch festnageln. Angesichts der Komplexität der Software sind wir meiner Meinung nach der Kurve voraus.

Moderne Autos setzen auf s / w. Wenn moderne Autos versagen, zum Beispiel der Motorcomputer, dann ist es normalerweise (wenn auch nicht immer, aber normalerweise) die Elektronik, die es auslöst, nicht das s / w.

Fragen Sie jeden Besitzer eines modernen Autos mit einem Steuergerät, wie lange es noch läuft, bis ein teurer Fehler auftritt. Ich bin fassungslos, wenn Sie 10 Jahre bekommen. Moderne Autos voller Elektronik und Sensoren sind erstaunlich unzuverlässig.

Wenn Sie Zuverlässigkeitstheorie studieren, wird die Antwort blind. Alles Mechanische (Softwareerwartung) hat eine Zuverlässigkeit im Steady-State, dh die Ausfallrate außerhalb der Bereiche Säuglingssterblichkeit und Abnutzung. Die Ausfallrate des Endartikels ist die Summe der Ausfallraten der Teile. Fügen Sie weitere Teile hinzu: Die Gesamtfehlerrate wird zu einer höheren Zahl. Die Herausforderung besteht dann darin, die Ausfallraten aller dieser Komponenten wirklich niedrig zu halten.

Wenn es um Dinge wie Zahnriemen- und Zylinderverschleiß geht und die Sauerstoffsensoren voll werden und die Anschlüsse ohmsch werden und die Drähte aufgrund von Vibrationen brechen - gibt es Techniken, mit denen die Ausfallrate verringert werden kann. Die Kosten steigen auch, wenn Sie dies tun.

Software hingegen weist eine konstante Ausfallrate auf. Trotz der Schwierigkeit, zeitweise Fehler zu finden, ist am Ende jede Software eine Wurstmaschine. Eingänge -> Aufgaben -> Ausgänge. Manchmal führt die Reihenfolge der Eingänge und die Kombination der Eingänge zu Fehlern mit erkennbaren Modi. Wenn dies passiert, haben Sie Ihren Defekt gefunden, beheben ihn und fahren fort.

Software, die keine (bekannten) Fehler aufweist, weist effektiv eine Fehlerrate von 0 auf. Sie wird für immer ohne Fehler ausgeführt. (Mittlere Zeit zwischen Ausfällen = 1 / Ausfallrate). Die Hardwareplattform wird zuerst ausfallen.

Software mit Fehlern wird möglicherweise nur so lange ausgeführt, bis die richtige Kombination von Eingabebedingungen im Laufe der Zeit dazu führt, dass sich der Fehler manifestiert.

Bei alledem geht es darum, die Ausfallraten physikalischer Dinge (die durch Verschleiß, Metallmigration in ICs, Eindringen von Wasser, Vibration usw. verursacht werden) mit einer Ausfallrate zu vergleichen, die im Wesentlichen einer endlichen Maschine entspricht, die genau das tut was seine Anweisungssequenz ihm sagt, zu tun.

(Sogar Dinge wie Alpha-Partikel, die Bits im RAM umdrehen, sind ein physikalisches Phänomen, kein Softwarefehler. Die Art und Weise, wie mit einem solchen Eveny umgegangen wird, kann jedoch ein Softwarefehler sein. Denken Sie jedoch daran, dass böse Alpha-Partikel nur eine weitere Eingabe für die Software waren. )

Der Unterschied zwischen Software und Autos besteht darin, dass Softwareentwickler zur Aufrechterhaltung der Integrität genaue Duplikate der Software von allen Benutzern der Software erstellen und Automobilhersteller zur Aufrechterhaltung der Integrität akzeptieren müssen, dass alle Benutzer fahren Deutlich andere Autos, weil die Art und Weise, wie Sie ein Auto fahren, das Auto verändert, aber die Art und Weise, wie Sie Software verwenden, die Software nicht notwendigerweise verändert.

Auf der anderen Seite,

Wenn Sie eine Möglichkeit hätten, das Öl in Ihrer Software zu überprüfen, würden Sie wissen, wann es ausfallen würde.

Wenn Sie die Möglichkeit hätten, das Öl in Ihrer Software zu ändern, könnten Sie wahrscheinlich die Lebensdauer um einige Monate verlängern.

Und um die Analogie sinnlos zu erweitern:

Flecken verändern das Öl nicht, sie ersetzen eine undichte Dichtung.

Updates ändern nicht das Öl, sie reparieren die Bremsen.

Releases ändern nicht das Öl, sondern fügen eher eine schlüssellose Zündung hinzu.

Autos, die kaputt gehen, sind nicht erträglich. Auch kann es Leben gefährden. Software, die zusammenbricht, wird toleriert, und Benutzer arbeiten daran oder akzeptieren es einfach. Die Nachfrage nach fehlerfreier Software ist gering.

Außerdem wird die Software in der Regel angepasst, da Sie nicht über 10000000 verschiedene Automodelle verfügen. Ich würde sagen, dass Wikimedia zuverlässig ist und tonnenweise Leute diese Software benutzen. Man könnte also sagen, dass viele Leute fehlerfreie oder zuverlässige Software verwenden. (WordPress, verschiedene Quellcodeverwaltungen, MySQL und SQLite sind ziemlich zuverlässig, usw.)

Software sind mathematische und logische Objekte, während Autos reale Objekte sind.

Außerdem können Sie leicht erkennen, wann ein Auto ein Problem hat und was das Problem ist, während es mit Software viel schwieriger sein kann: Stellen Sie sich vor, jemand hat ein Problem mit einem Computer und jemand hat ein Problem mit einem Auto; Diese Person kann besser wissen, was falsch ist, weil Autos weniger abstrakt sind als Computer.

Ich sage nicht, dass Computer schwerer zu verstehen sind: Autos beinhalten auch viele physikalische Gesetze wie Thermodynamik, Elektronik und Chemie.

Sie könnten diesen Vergleich auch extrapolieren und sagen: "Warum ist ein Hammer zuverlässiger als eine Sekretärin?".

Ich denke, die Frage ist nicht wirklich relevant, aber ich denke, sie zeigt sehr gut, wie ein Mangel an guter mathematischer Ausbildung das Verständnis einer bestimmten Art von System beeinflussen kann.

Software ist viel komplexer als ein Auto, auch wenn das Auto aus Tausenden von Komponenten besteht.

Wenn ein Auto so komplex wie Software wäre, würden alle Komponenten des Autos von allen anderen Komponenten des Autos abhängen, und viele Autokomponenten würden direkt mit vielen anderen Autokomponenten verknüpft sein.

Alle Autos der Welt gleichen in ihrer Komplexität kaum der ursprünglichen Unix-Software.