なぜソフトウェアは自動車ほど信頼性がないのですか？[閉まっている]

ユーザーにこの質問をしてもらいました。車が故障することはわかっていますが、それは物理的なものが原因です（ソフトウェアが関与していない限り！）。

私はソフトウェアはもっと若い産業だと答えようとしましたが、ユーザーは「自動車産業はより少ない人でより安定し、信頼できるようになりませんでしたか？」と反論しました。

また、ソフトウェアはもっと複雑だと答えようとしましたが、ユーザーは車を構成する部品が何千もあると反論しました。車の設計と製造を行う人々は一般に、そのコンポーネントを非常によく知っていますが、最終的にはすべて一緒に作業することになります。

それでは、なぜソフトウェアは自動車ほど信頼性が高くないのでしょうか？

あなたの質問の前提は単に間違っています。ソフトウェアは車よりも「信頼性が低い」というわけではありません。何十億ものデバイスが何十億もあり、何年もの間、何の問題もなく組み込みソフトウェアを24時間365日実行しています。ヘック、それのいくつかはあるに車、および制御/エンジンを監視します。それでは、車自体がソフトウェアに依存している場合、ソフトウェアはどのように車よりも信頼性が低いのでしょうか？

ソフトウェアと機械部品を設計しています。

それは複雑です。

現代のソフトウェアには何百万もの「部品」があるためです。

ソフトウェア部品は非常に複雑であり、多くの状態があります。機械的に動かない部分には状態がありません。

機械的な可動部品には位置があります（1つの変数）。

実行中の1MbのRAMを使用するプログラムには、100万バイトの状態があります。これは、通常の機械システムよりもはるかに多くの状態です。

まれにしか発生しないため、テストされない状態の組み合わせがあります。機械システム（自動車など）では、動作中に機械部品が互いにぶつからないことを簡単に確認できます。私が職場で使用している機械式CADソフトウェアは、自動的にそれを行います。

目に見えない非接触部品から機械を構築し、数百万の可動部品があり、それらすべてが互いに見逃していた場合、単純なプログラムのようになります。

「hello world」でさえ、オペレーティングシステム上で実行されます。古い8ビットシステムとミニコンピューターのオペレーティングシステムは、シンプルであるため非常に信頼性が高くなりました。

DLLや共有ライブラリなどは、ウイルスの更新やソフトウェアのインストールの一部として置き換えられ、目的のプログラムが機能しなくなります。車のタイヤを自転車のタイヤに交換するようなものです。ライブラリ関数のエッジ状態のいくつかは干渉します（プログラムが期待するように動作しません）。

オブジェクト間の多くの設計されていない相互作用（ポインターの再利用、配列境界のオーバーフロー）を許可しないJavaのような言語で書かれたプログラムは、それらを動作させると一般にかなり信頼できます。
静的ライブラリを備えたオペレーティングシステムを使用する場合、プログラムが動作すると、動作し続けるだけです（ただし、状態サイズに基づいて多くのエッジ条件があります）。

Dave Parnasは、プログラムの状態を小さくすることにより、ソフトウェアの信頼性を高めることについて書いています。厳密な関数型プログラミングの担当者は、単一の静的割り当てを強制することで同じことをしています。

それは消費者の選択の問題です。

消費者が私のホンダシビックと同じくらい信頼性の高いソフトウェアを要求した場合（私の古いフォードマーベリックとは対照的に）、それはそうでしょう。一部の組織は、信頼性の高いソフトウェアを求めており、通常は組み込みソフトウェア、場合によっては宇宙ミッションや航空交通管制などの安全性が重要なものに使用します。ソフトウェアはまだ完全ではありませんが、車でもありません。

ただし、顧客はソフトウェアに他の品質を要求し、ほとんどの場合、機能性が低く、確かに高価で、信頼性が高いという理由だけで出荷されるソフトウェアに対しては支払いません。

車を構成する何千もの部品があります。

コンピューター（および関連するソフトウェア）だけがそんなに簡単だった場合。

コンピューターには何ギガバイトのメモリがありますか？数十億のフリップフロップ？テラバイトのディスク？何兆もの「動く」部品？

ソフトウェアには、数万または数十万の個別のコード行が実行されている場合があります。さらに、単体テストとツールの多く（またはそれ以上）。

いいえ。「車も複雑です」という議論は二段です。ソフトウェアは自動車よりもはるかに複雑です。

燃焼エンジンを機能させる原理、および自動車を構成するすべてのコンポーネントは、過去1世紀ではあまり変化していません。確かに進化的な改善とハイブリッド車がありましたが、基本的なコンポーネントは同じです。エンジン、ドライブトレインなどがあります。コンセプトカーや超高価な超高速ブガッティヴェイロンでさえ、同じ基本構造で構築されています。要するに、車の設計はよく知られている問題です。

ソフトウェアの開発とは対照的です。

• 顧客は、開始時に何が欲しいかを知りません。彼らは豪華なジェット機について話し始めますが、コストに気付いたとき、彼らはあなたが足で動くスクーターのコストのためにそれを構築することを望みます。
• 車の設計には、アイデアからコンセプトカーに至るまでに何年もかかり、そこから製造するまでにはさらに何年もかかります。ソフトウェアでこれほど贅沢な時間を過ごしたのはいつですか？
• 車の部品は金属の鋳造品ですが、ソフトウェアコンポーネントは形状やインターフェイスを頻繁に変更することがあります。
• 製造プロセスは完全に異なります。車の場合、部品は大量に製造され、同じ部品が異なる車両で使用されます。ソフトウェアでは、ほとんどすべてが手作りです。

要するに、自動車がソフトウェアよりも「信頼性が高い」と認識される理由はいくつかあります。私はちょうどカップルを思いついた。

車は信頼できます。ほとんどのソフトウェアも同様です。

しかし...カスタムカーとカスタムソフトウェアには両方とも問題があります。

1970年に改造されたマッスルカー、いじくり回し、微調整があり、故障があり、元の状態のままにしておかなければ得られなかったあらゆる種類の馬鹿げた問題を抱える本物の自動車愛好家。しかし...その後、彼はスーパーチャージャーを持っていません...

あなたが運転する車は何度も作られているため、建設プロセスは非常に洗練されており、同じ車を生産ラインで何度も作ることができます。

ゼロから構築された、他に類を見ない複雑な最先端の車であった場合、信頼性はそれほど高くありません。たとえば、フォーミュラ1のレーシングカーの故障率がどれほど高いかを調べてください。1人または2人がレースごとに故障するのは一般的です。

新しいソフトウェアは常に一度限りです。プログラマーがコーディングしたものは、以前にコーディングされたことはありません。このシナリオで本当に高い品質を得るには、ほとんどの製品にとって法外なコストがかかります。重要な新しいソフトウェアはすべて、事実上プロトタイプです。

余談ですが、これは、従来のエンジニアリング技術をソフトウェアエンジニアリングに適用することが災害である主な理由の1つです。

1. 自動車メーカーは、「最終」製品を生産する前に、仕様全体を明確にします。
2. 自動車ユーザーは、デザイナーが予期しなかった愚かなことをする傾向はありません。
3. ほとんどのソフトウェアは年に何回も更新されることが予想されますが、車は年に1回（通常）だけ「更新」されます。

続行できますが、ブラウザがクラッシュしようとしているように感じます...

実際には非常に単純な理由があります。

お金を稼ぐソフトウェアは、市場シェアを獲得するソフトウェアです。多くの場合、最初にソフトウェアを市場に投入する会社は、たとえそのソフトウェアが特定の市場で最高の製品でなくても、市場シェアの大半を占める企業になります。

そのため、ソフトウェアは、後で完全にリリースされるのではなく、より早く不完全にリリースされることに重点が置かれます。

私はこれまでのところほとんどの答えが好きです。ここに私のスピンがあります。

故障のコストは、ソフトウェアよりも車にとって厳しい

車の故障は生命を犠牲にする可能性があります。生命にかかわらない車両の故障でさえ、ユーザーにとって非常に目に見える不便です。ソフトウェアの障害とは、実稼働サポートの貧弱な樹液が残業することを意味します。そして、その人がフルタイムの免除された従業員なら、それはまあ、それはまったくそれほど高価ではありません。実際、時間外労働の無料化は実際には1時間あたりの人件費を削減するため、質の悪さと管理の悪さは報われます！

もちろん、これは使用するソフトウェアの種類に依存します（武器システム、アビオニクス、または医療システムに電力を供給することも生活に影響を与える可能性があります）。かなり具体的で痛みを伴う。多くの場合、ソフトウェア障害には回避策があります。

別の考え：車は信頼できるように見えますが、車がうまく機能していても継続的な明確なメンテナンスコストがあります。一方、ソフトウェアはインストール時に既に破損していることが多く、多くの場合、時間の経過とともに変更する必要がありますが、文化的には、誰もメンテナンスにお金を払いたがりません。

さて、車はほとんどの歴史においてかなり信頼性が低く、間違いなく学習曲線があります。自動車は約60年にわたって大規模に生産されてきましたが、ソフトウェアは約20〜25の間だけ大規模に生産されています。大規模とは、基本的に、大衆がそれを購入/使用するのに十分な大きさを意味し、作成手順を完璧にする方法を見つけ出すための本当に大きなインセンティブがあります。

私は車をアプリケーションとして考えるのが好きです。OSは、アプリケーションが実行される道です。

道路と車の間のインターフェースは明確に定義されています。十分にテストされており、下位互換性について広範囲にチェックされています（インターフェイスがシンプルなので簡単です）。それでも、下位互換性の問題がいくつかあります。「ファリー」タイプの車は、「泥道」タイプの道路を走るのに苦労します。

それでも、道路と同じようにOSには継続的なメンテナンスが必要です。橋が切れる。車はスノーチェーンを装着し、アプリケーションが破損し、OSが使用するディスクやファイルを破損するなど、道路を破壊します。

アプリケーションは1つのOSで作成されます。ただし、一般に、異なるバージョンのOS（異なるタイプの道路）を実行する必要があります。したがって、夕食用に最適化されたアプリは、正しいOS（高速道路）で実行されている限り問題なくスムーズに実行できますが、他の汎用（単純な）コードはあらゆるタイプの道路で正常に実行されます。

アプリケーションとOS間のインターフェイスは定義されていますが、非常に複雑であり、常にわずかに変動します。特に、ユーザーが拡張機能を使用して独自のOSを変更できるようにしているためです。政府がユーザーに道路の変更を許可した場合、さらに多くのクラッシュが発生します。

OSを変更するユーザーの能力を制限し始めると、アプリケーションの信頼性はほぼ安定します。それらすべての組み込みデバイスを見てください。OSの近くにいるユーザーを中断せずに24時間年中無休で正常に実行させません。

だから私はそれが信頼できないソフトウェアではないと言うでしょう。ユーザーがアプリケーションのために高速道路に穴を掘っていると言っているようなものです。去年掘った穴にアプリケーションがクラッシュして、忘れてしまったね。

まず、ユーザーは、この世界には信頼性の高いソフトウェアが存在することさえ知らないことを知る必要があります。テレビのクラッシュを見たことがありますか？私でもない。

主な理由は、ソフトウェアが重要でないからだと思います。重要でないということは、開発者以外の人には進行状況が見えないことを意味します。たとえば、私が車​​を作っている場合、さまざまな部品を組み立てて見ると、ますます車のように見えます。ただし、プログラミングを見てみると、奇妙なパターンをしている緑色のテキストで黒い画面に呪いをかけ、突然パターンが少し変わったとき、私は興奮しすぎます。

そのため、普通の人はソフトウェアの複雑さを理解していません。彼らは窓を見たとき、彼らはプログラム全体を見ると思うが、それはまさしく間違っている。

また、ソフトウェアは自動車よりもはるかに頻繁にカスタマイズされています。あなたが車をカスタマイズするとき、それは目に見えて愚かであるので、あなたはそのデザインに反しません。私のエンジンが車の前にある場合、それを後ろに動かすことは大惨事になるでしょう。ただし、ソフトウェアは重要ではないので、クライアントがデザインに対して完全に何かをするように頼むと、彼らがしていることは愚かであるという兆候は得られません（あなたを除いて、彼らは聞きません）予想通りに動作しないことに驚くでしょう。

1. 情報共有の欠如（プログラマーは単独または小グループで飛行します-カーデザイナーは大企業内の相互接続されたチームと協力し、彼らはすべて知識を共有します。他の人から;これはまた、オープンソースプログラムやオンラインリソースのようなものが非常に重要な理由です）
2. フィールドエントラントへの期待（車のデザイナーが最初の5-10年だけわずかに役立つだけなら大丈夫ですが、プログラマーがインタビューに行って5-10年あまり役に立たないと言ったら、インタビューは終わりました）
3. 侵入テストの欠如（資金不足、合法性の問題などのため;ただし、自動車メーカーは、レンガの壁に車を押し込んだり、風洞を持ったり、比較的簡単な性能要件を持っているなど）
4. 情報の透明性（ほとんどのソフトウェアがどのように機能するかはわかりません。面接、プレスリリース、広告などに基づいて推測したり、推測したりします。ただし、車の場合、ほとんどのものはすぐに見ることができます）
5. 固有の知識のカプセル化（フレームを一緒に溶接する人/ロボットは、安定性制御システムの背後にある数学を知る必要はありません。プログラマーは、平均的な人には知られていない何千または何万ものことについて知識が必要ですが、自動車デザイナーは数百または数千を知る必要がある）
6. タンジビリティ（見たときに役立ちます）
7. Age of Field（車両設計は数千年前、電動車両設計は250年以上前[蒸気エンジンなど]）
8. サブシステムの重大性（パワーロック、パワーウィンドウ、HVAC、フロントガラスワイパー、窓の破損、ハブキャップの紛失、パンクしたタイヤ[新しいものを履く]、ラジオ、ライトまたは2つ、リモートエントリなど、コンピューター上の何かが壊れた場合、それは多くの場合SHTFシナリオです）
9. 相互依存性（1台のコンピューターが故障した場合、数百または数千の他のコンピューターが影響を受けることは珍しくありません。 -3）
10. 全面的な非難（コンピューターの一部または数千台のうちの1台のコンピューターがシステムを破壊して傷つけた場合、その原因はコンピューター全体に及ぶか、後者の場合はコンピューターのネットワーク全体に広がります。自動車が車に衝突した場合ブレーキの故障、または車が失速して高速道路で再起動しない場合、個々の車の部分のみが非難される）
11. 有限システム対無限システム（車は非常に多くの荷物を詰め込むことができるだけであり、限られた条件下でのみ機能することが期待されています。たとえば、ジープのような車両だけができる地形でBMWを運転しないでください。ただし、可能性は事実上無限です-常に新しいもの、新しいAPI、新しいOS、新しいセキュリティホール、iPad、携帯電話ソフトウェア、新しいthis、new thatなどがあります）
12. 必要な知識体系の範囲（130-140のIQを持っている人は、自動車について知っていることのほとんどすべてを学ぶことができますが、コンピューターとプログラミングについて知っていることのほんの一部しか学ぶことができませんでした）

ロジック全体に欠陥がある単純な理由：

機械装置は、単に入出力に縮小できます。このI / O操作を実現するために部品の数を増やしても、I / O操作は変わりません。したがって、システムを完全に理解できます。

一方、ソフトウェアにはInput-> Process-> Outputがあります。この性質のため、システムを完全に予測または理解することはできません。

ドナルド・ラムズフェルドは次のように言っています。

「既知の既知のものがあります。知っていることがわかっていることがあります。また、既知の未知のものがあることも知っています。つまり、わからないこともあるとわかっているということです。しかし、未知の未知の要素もあります。未知の未知の要素です。” — 米国国防長官ドナルド・ラムズフェルド

要約すれば：

• 機械装置とは、既知の既知の未知のシステムです。
• ソフトウェアには上記のものがありますが、不明なものもあります。

これは愚かな質問です（あなたからではなく、元の人から）。

これは、コンピューターを嫌いながら、一日中eBayに費やしている父（メカニック）のように聞こえます。

「なぜtreeよりも木が信頼性が高いのか」と尋ねるようなものです。

まず第一に、私は30台（はい、30台以上）のコンピューターを所有しており、そのうちの1台もショップにありませんでした。私はちょうど私の修理に1400ドルを費やしました。自動車修理店とコンピューター修理の数を数えます。繰り返しますが、愚かなアナロジーです。

車はスチール、コンピュータープラスチックで作られています。車はすべての気象条件で動作し、コンピューターは屋内で使用するように設計されています。

私のCommodore 64（26歳）は完全に機能し、修理されていません。私の車（10歳未満）の両方が非常に広範囲の修理をしました。数千時間、何千時間も使用されている26歳の車を見せてください。それでも、工場の新品のときとまったく同じように動作します。

ソフトウェアはビットに基づいています：0および1。車は（大部分）機械部品に基づいています。

機械部品は摩耗したり、誤動作したりする場合がありますが、それでも作業が必要です。ブレーキが摩耗したり、バルブに漏れが生じたりしますが、修理ができるまで車はまだほとんど機能しています。

ソフトウェアには、ほとんどの場合、段階的な失敗というものはありません。動作するか、壊れます。ゼロによる除算は「ほぼ正しい」わけではありません。それは単なるエラーです。十分なスペースなしでドライブに保存しようとすると、すべてのデータを強制的に押し込むことはできません。行きません。

ソフトウェアは必ずしも自動車ほど信頼性が低いとは思いませんが、ソフトウェアが故障すると、徐々にではなく、すぐに故障します。

私ははるかに良いアナロジーを持っていると思います。救急車を顧客の仕様に合わせて構築する会社を取り上げてください。ベースプラットフォーム（たとえば、完全に機能するストリートリーガルRVカットアウェイシャーシ）では、フレーム、充電システム、フィラースパウト、サスペンションなどのいくつかのポイントで変更が必要です。顧客の要望を満たしながら。

次に、救急車本体自体を構築する必要があります。これには、政府や他の機関の複数の層からの規制要件も含まれています。ファンキーな座席配置または保管システムに対する顧客の要望を依然として満たしながら。また、購入と展開のスケジュールが異なる世界中から100人の顧客がいることを忘れないでください。多くの場合、全体の完全なリエンジニアリングが必要です。

車？それは簡単です。構築されたものを購入し、デザインのどの側面にも直接的な影響はありません。まだ設計およびテストされていないものを実際に指定することはできないため、色の選択も人為的です。ある意味では、「顧客」ではなく「市場」のみが存在します。一部の市場向けに生産された市販のソフトウェアは、一般的に地元のディーラーで手に入れる車と同じくらい信頼性が高いと主張します。

車はあなたが思っているほど実際には信頼できません。全体が失敗することなく、障害が長時間隠されたままになる（または無視される）だけです。車からオイルやクーラントが漏れていますか？番号？本気ですか？あなたはおそらく間違っています...おそらくあなたがまだ気づいていないどこかに非常に少量を漏らしているだけです...今、それをサスペンション、ボディパネル、インテリアなどに拡張しますまだ何かおかしなものを見つけることができなかった車に出会った。しかし、部品の大部分は輸送の使命に不必要です。コンピューターではそうではありません。コンピューターのほぼすべての部分が重要です。

それは古いアナログ対デジタルの議論であり、再パッケージ化されたばかりです。すべてが完璧である限り、デジタルテレビは素晴らしいです。何かがおかしくなった瞬間、音声が途切れ、ビデオがブロックされて役に立たなくなります。簡単に無視される、ちょっとしたヒスノイズや静的ノイズが発生するアナログテレビと比較してください。

第一に、もちろんいくつかのswは完全に信頼性が高く、車、特にイギリスとイタリアの車は必ずしもそれほど信頼できるとは限りません。

つまり、自動車用ソフトウェアを使用した私の経験は、次の2つのことになるということです。

• 保証費用。swが失敗すると、再起動します。おそらく、あなたはバグレポートを提出するでしょう。または、高価なサポート契約を使用します。あなたの車が故障したら、あなたはそれを持ち込み、保証の下で修理されることを要求します。これはメーカーに100ドル以上の費用がかかります。swの失敗ごとにメーカーに2ドルかかる場合、swの方が信頼性が高いと確信しています。

• JD Powers（およびその他の品質ランキング）。JD PowersはThingsGoneWrong（これは何でもかまいません）を調査します。そしてそのランキングが本当に悪い場合、人々は単にあなたの車を買わないでしょう、少なくとも利益を上げるのに十分なお金のために。swにJD Powersがあり、人々がそれを本当に気にかけているなら、swの方が信頼性が高いと確信しています。

したがって、信頼性の低い車を製造する場合、保証費用は利益のすべてをすぐに使い果たし、数年後には品質の悪いランキングは車をまったく売らないことを意味します。信頼性の低いswを作成すると、ユーザーから苦情が出て、高価なサポート契約を販売できるようになります。

自動車の信頼性と安全性が義務付けられています。多くの（ほとんどの？）国では、最低レベルの信頼性と安全性を持ち、最悪のシナリオ（それが何であれ）についてテストされることが法律で義務付けられています。ほとんどの場合、商用ソフトウェアはそうではありません。

ソフトウェアには他にも法的な意味合いがありますが、「保存」ボタンを押すたびにソフトウェアがクラッシュする場合、これは単にパッチ/修正の問題であり、続行することに注意することが重要です。インジケータをオンにするたびに車がクラッシュした場合、これは非常に悪いことです。Microsoft Outlookが予期せずクラッシュすることなく実行されることは、SUVが予期せずクラッシュすることなく実行されるため、それほど重要ではありません。

そうは言っても、自動車の仕組みと同じかそれ以上の責任を負っているソフトウェアは他にもあります。飛行機とミサイル誘導システムは信頼できるものでなければなりません。危機にlivesしている生命があります！これらが平均的な自動車よりも厳密にテストされることを望むでしょう。

自動車業界はテストのために「ベータ」カーを一般に公開していません。自動車業界も製品を出荷する環境について心配する必要はありませんが、他の多くのことについて心配する必要があります。ソフトウェア業界は最初に根本的に異なっている（私たち全員が知っているように）と言うので、信頼性と複雑さは本当に示唆に富んでいます。私の意見では、車はソフトウェアよりも複雑ですが、何が機能しているかを見るのは簡単です

• 車の底にあるのは仮想ではなく、テストが簡単になります（ただし、より高価です）
• 彼らはソフトウェア業界よりもはるかに早く始まりました。たとえ彼らが少数であったとしても、彼らが集めた実践と知識を最小限にすることはできません。ソフトウェア産業は、それと比較してまだまだ小さいです。
• 自動車業界はすべて、特に過去数十年間、ドライバーを殺す車を製造しないという法律と倫理に拘束されています。

したがって、ソフトウェアは車よりも信頼性が低く、多くの種類のソフトウェアに当てはまり、他の分野（セキュリティ、航空など）には完全に間違っている可能性があるという声明は、ソフトウェアが少なくとも最も信頼できるそれらの地域の車の。単にこれらの分野が重要であり、私がこれらの分野でのみ知っていることから、ソフトウェアは自動車産業と比較できるからです。

これは私たちをこれに導きます：ほとんどのソフトウェアは彼らの領域で重要であると考えられていません。そのように考えられた場合、信頼できるソフトウェアがあり、それらで見つかる唯一の問題は、ソフトウェア自体ではなく、環境に関連する問題です（したがって、それを制御できれば、実質的に問題はありません）。ただし、ほとんどのソフトウェアエディターはこれらの重要な領域では動作しません。もちろん、ある程度の品質を提供する必要がありますが、できるだけ早くソフトウェアを提供する必要があります（私の意見では）。しかし、優れたソフトウェアには、優れたプロジェクト管理、堅固な仕様、優れた設計、そしてそれを使った人たちの優れたスキルが必要です（再開するには）それはただそれを作ることであり、私たちはそれを売ることについても話していません...

これにはすべて時間がかかるため、お金が必要です。私はあなたが作るあなたは、私はほとんどの時間を言っている何のために払っているものを手に入れるとは言わないよあなたのために投資するものを決して少ない（あなたがねじ込まれてしまった場合を除き、しかし、あなたは...ので、何も生成しない）、時にはそれ以上。 。

車はそれほど複雑ではないと思います。しかし、そうだとしても、ソフトウェアの信頼性は低いとは思いません。ただし、ソフトウェアの信頼性の不一致につながるより重要な要因があると思います。

1. ソフトウェアに含まれる抽象化。これにより、ソフトウェアの作成者は、物事が実際にどのように機能しているかを誤解します。時間が経つにつれて、ますます抽象化が追加されます。たとえば、アセンブリ言語を使用すると、マシンを直接制御できます。Cはより抽象化されていますが、それでもマシンに近いものです。Java、C＃、そして次に来るものは、マシンで起こることをかなり抽象化している。もう1つの例は、ソフトウェアレベルでネットワークがどのように発生するかを理解したいプログラマーの場合、インフラストラクチャ（ソフトウェアとして）がCで記述されているため、Cでプログラミングすることを知っておく必要があります。

2. さまざまな経験メーカーの知識はさまざまな結果につながります。開発者が異なれば、信頼性の異なるソフトウェアが作成されます。自動車メーカーについても同じことが言えます。ただし、エディターとコンパイラーを使用したり、IDE（統合開発環境）をインストールしたりできる人なら誰でも、ソフトウェアAndを無料で作成できます。車を作るには、莫大な投資、工場が必要です（一部の人は車を使わずに車を作ることができますが、あなたの周りのどこにでもそれを見つけることはできません）。あなたが莫大な投資をするという事実は、あなたがその分野で最高のものを雇おうとすることを意味します。しかし、自動車にはまだ信頼性の問題があります。あなたがそれに気づいているなら、何百万台もの車が深刻な[バグ]のために市場から撤回されています。私の車では、メーカーは同じ年に購入したすべての車のブレーキクリッパーを無料で交換します。

3. ソフトウェアのバグは、通常、車よりもユーザーに見えます。これは、ユーザーとソフトウェア間の対話性と応答の結果です。車では、「アクセルを踏むと車が加速する」、壊れる、曲がる、ライト、ミラーなどの詳細が少ないことに注意を払っています。ソフトウェアでは、通常、ユーザーがクリック/入力するたびに応答。そのため、ソフトウェアにバグが発生する可能性があり、ユーザーがすぐに気付く点が多くあります。これにより、ユーザーは自動車よりも信頼性が低いと考えます。

4. ハッキングと攻撃。ソフトウェアが広く使用されるほど、ハッキング攻撃を受ける割合が高くなります。これを車の盗難と比較できます。私にとっても、所有者や鍵以外の人が車を開けると、車の信頼性が損なわれます。ただし、攻撃者は見えないため、車よりもソフトウェアを攻撃する方が簡単です。そのため、ソフトウェアが侵害されると、人々は、それが何のために作られたとしても信頼できるにもかかわらず、信頼できないと思い込みます。

それは他のすべてのようです...それが動作するとき、あなたは気にしません...それが壊れたとき（またはあなたが望む/期待する方法で動作しません）あなたが気にします。

飛行機を考えてください。多くの人々が、人々をハイジャックしたり爆破したりすることを心配しています。しかし、実際には、負のイベントの数は、毎日のフライトの数に比べてごくわずかです。（1日でさらに多くのフライトがあり、ハイジャックまたは爆撃されたことがあります。.一体、ハイジャックまたは爆撃されようとしました。）

あなたが見て、どのように測定するかはすべてです。

実際には非常に簡単です。車は古い技術です。確かに、最近は（壊れる）添えものがありますが、初期の車を見ると、それらはたくさん壊れています。

自動車の機械部品の背後にある「テクノロジー」は数百年前から存在し、内燃機関も長い間存在しており、導入された時点で多くの問題がありました。

一部のマネージドプラットフォームでは、メモリの問題はほとんど過去のものであると考えてください。ソフトウェアに数百年を与えれば、私たちもそれを打ち消すでしょう。実際、ソフトウェアの複雑さを考えると、私たちは時代を先取りしていると思います。

現代の車はs / wに依存しています。現代の車が故障すると、たとえばエンジンコンピューターが故障すると、通常（常にではありませんが、通常）、S / Wではなく、それを点火した電子機器が故障します。

ECUを搭載した最新の車の所有者に、高価な故障が発生するまでの走行時間を尋ねます。あなたが10年になれば私はI然とするでしょう。エレクトロニクスとセンサーに満ちた現代の車は驚くほど信頼性が低い。

信頼性理論を研究すれば、答えは盲目的に明らかになります。機械的なもの（ソフトウェアを期待するもの）はすべて、安定状態の信頼性を持っています。これは、乳児死亡および摩耗領域の外での故障率です。最終品目の故障率は、部品の故障率の合計です。部品を追加します。総故障率が高い数値になります。課題は、これらすべてのコンポーネントの故障率を本当に低くすることです。

タイミングベルトやシリンダーの摩耗、酸素センサーががらくたになっている、コネクタがオームになっている、振動による断線などの場合、故障率を減らすために使用できる技術があります。これを行うと、コストも上がります。

一方、ソフトウェアの障害率は一定です。時々欠陥を見つけるのは困難ですが、結局のところ、すべてのソフトウェアはソーセージマシンです。入力->処理->出力。入力の順序と入力の組み合わせが、検出可能なモードで障害を引き起こす場合があります。それが起こったとき、あなたはあなたの欠陥を見つけた、あなたはそれを修正し、そして先へ進む。

（既知の）欠陥のないソフトウェアの障害率は事実上0です。障害なしで永久に実行されます。（平均故障間隔= 1 /故障率）。ハードウェアプラットフォームが最初に失敗します。

欠陥のあるソフトウェアは、入力条件の適切な組み合わせが時間の経過とともに欠陥を顕在化させるまでのみ実行される可能性があります。

このすべてにおけるFALLACYは、物理的なもの（摩耗、ICの金属移行、水の浸入、振動などが原因）の故障率を、本質的に有限状態マシンである故障率と単純に正確に比較することです。その命令シーケンスが実行するように指示するもの。

（RAMでアルファ粒子がビットを反転するようなことでも、物理的な現象であり、ソフトウェアの欠陥ではありません。そのような均等な処理方法はソフトウェアの欠陥である場合がありますが、厄介なアルファ粒子はソフトウェアへの単なる入力であることに注意してください。 ）

ソフトウェアと自動車の違いは、ソフトウェア開発者が健全性を維持するために、ソフトウェアのすべてのユーザーがソフトウェアの正確な複製を駆動し、自動車メーカーが健全性を維持するために、すべてのユーザーが運転することを受け入れる必要があることです車を運転する方法によって車が変わるが、ソフトウェアを使用する方法が必ずしもソフトウェアを変えるわけではないため、大幅に異なる車。

一方、

ソフトウェアのオイルをチェックする方法があれば、いつ失敗するかがわかります。

ソフトウェアのオイルを変更する方法があれば、おそらく数か月まで寿命を延ばすことができるでしょう。

そして、類推を無意味に拡張するには：

パッチはオイルを変えるものではなく、漏れやすいガスケットを交換するものです。

アップデートはオイルを変更するのではなく、ブレーキを修正します。

リリースはオイルを変えるものではなく、キーレスイグニッションを追加するようなものです。

故障した車は耐えられません。また、生命を危険にさらす可能性があります。故障したソフトウェアは許容され、ユーザーはそれを回避するか、単に受け入れるだけです。バグのないソフトウェアに対する需要はあまりありません。

また、ソフトウェアはカスタマイズされる傾向があり、10000000種類の車のモデルを所有することはできません。ウィキメディアは信頼性が高く、多くの人々がそのソフトウェアを使用していると思います。したがって、多くの人がバグのない、または信頼できるソフトウェアを使用していると言えます。（wordpress、さまざまなソース管理、mysqlおよびsqliteは非常に信頼性が高いなど）

ソフトウェアは数学と論理のオブジェクトですが、車は実際のオブジェクトです。

さらに、車にはいつ問題が発生し、何が問題なのかを簡単に知ることができますが、ソフトウェアではさらに困難になる可能性があります。コンピューターに問題がある人と車に問題がある人を想像してください。車はコンピューターほど抽象的ではないため、この人は何が悪いのかをよりよく知ることができます。

コンピューターは理解しにくいと言っているわけではありません。車には、熱力学、電子工学、化学などの多くの物理法則が関係しています。

「なぜハンマーは秘書よりも信頼性が高いのか」と言って、この比較を外挿することもできます。

質問は本当に関連があるとは思いませんが、良い数学教育の欠如が特定の種類のシステムの理解にどのように影響するかを本当によく示していると思います。

車は数千のコンポーネントで構成されていても、ソフトウェアは車よりもはるかに複雑です。

車がソフトウェアと同じくらい複雑な場合、車のすべてのコンポーネントは車の他のすべてのコンポーネントに依存し、多くの車のコンポーネントは他の多くの車のコンポーネントと直接リンクされます。

世界のすべての自動車は、元のUnixソフトウェアの複雑さにほとんど匹敵しません。