IT業界では、他の業界と同様に、大規模で障害のないプロジェクトを迅速に提供できないのはなぜですか？

National GeographicのMegaStructuresシリーズを見て、大規模なプロジェクトがどれほど高速に完了するかを知りました。準備作業（設計、仕様など）が紙の上で行われると、巨大なプロジェクトの実現自体はわずか数年、時には数ヶ月かかります。

たとえば、エアバスA380は 「2000年12月19日に正式に打ち上げられました」、「2005年3月上旬に」、航空機はすでにテストされています。同じことは、巨大な石油タンカー、高層ビルなどにも当てはまります。

これをソフトウェア業界の遅れと比較すると、ほとんどのITプロジェクトがなぜこんなに遅いのか、より正確には、なぜ同じ規模で同じ規模で、十分な人数の人がいるほど速くて障害がないのか疑問に思わずにはいられません。

エアバスA380などのプロジェクトは、両方を提示します。

• 予期せぬ主なリスク：これは最初に製造された航空機ではありませんが、技術の限界を押し広げており、小さな旅客機でうまく機能したものは、物理的な制約のために大きな旅客機では機能しません。同様に、たとえばボーイング747が完成した1969年には利用できなかったため、まだ使用されていない新しい技術が使用されています。

• 一般的な人的資源と管理に関連するリスク：プロジェクトの途中で辞める人々、休暇中に人に連絡することができない、通常の人為的ミスなど

これらのリスクにより、人々はまだこれらの大型旅客機のようなプロジェクトを非常に短い期間で達成しており、配達の遅延にもかかわらず、それらのプロジェクトは依然として非常に成功しており、高品質です。

ソフトウェア開発に関しては、プロジェクトは旅客機ほど大きく複雑ではなく（技術的にも管理の面でも）、現実世界からの予期しないリスクがわずかに少なくなっています。

それでも、ほとんどのITプロジェクトは遅くて遅く、プロジェクトにさらに開発者を追加することは解決策ではありません（10人の開発者から2000人のチームに行くと、プロジェクトをより速く提供できる場合があります。計画し、それをまったく完了しないリスクを高めます）。

まだ配信されているものには多くのバグが含まれていることが多く、連続したサービスパックと定期的な更新が必要です（元の製品のバグにパッチを当てて航空機がcrash落するのを防ぐために、週に2回すべてのAirbus A380に「更新プログラムをインストール」することを想定してください）。

そのような違いはどのように説明できますか？それは、ソフトウェア開発業界が若すぎて、大規模でほぼ完璧な製品を非常に高速に提供するために、単一のプロジェクトで数千人を管理できないという事実だけに起因するのでしょうか？

エド・ユアドンの死の行進は、これらのメタタイプの質問の多くに触れています。

一般に、ソフトウェア業界には以下の多くが欠けており、大規模なプロジェクトの邪魔になります。

• 標準化と作業項目の内訳。

  • これは確かに良くなりましたが、大きなシステムを破壊するための設計構造はまだありません。ある意味では、ソフトウェアは特定のプロジェクトに必要なものに同意することさえできず、物事をコンポーネントに分解することができなくなります。
  • 航空宇宙、ビル建設、自動車などはすべて、非常にコンポーネント駆動型のアーキテクチャを備えており、かなり緊密なインターフェースを備えており、完全に並行した開発が可能です。ソフトウェアは、対応する領域での過剰なブリードスルーを依然として許可します。

• 成功した同様のプロジェクトの大部分。A380はありませんでした最初の大きな飛行機エアバスが組み込まれています。そこには大きなソフトウェアアプリケーションがたくさんありますが、それらの多くは何らかの面で劇的に苦しんでおり、「成功」と呼ばれるには近づきません。

• 多数の同様で成功したプロジェクトに携わった多くのデザイナーとビルダー。成功したプロジェクトの問題に関連して、そこにいた人間の才能を持たないことは、再現性の観点から物事を非常に困難にします。

• 同じことを2回「絶対に」ビルドしない。多くの点で、飛行機は他の飛行機と似ています。翼、エンジン、座席などがあります。大規模なソフトウェアプロジェクトはめったに繰り返されません。各OSカーネルは大きく異なります。ファイルシステムの格差を見てください。それに、本当にユニークなOSはいくつありますか？大きなものは、ある時点で基本アイテムのクローンになります。AIX、Solaris、HP-UX、... AT＆T System Vに戻ります。Windowsには、反復ごとに信じられないほどの量のドラッグがありました。通常、Linuxの亜種はすべて、Linusが開始したのと同じコアに戻ります。バリアントは、真に独自の独自のOSよりも速く伝播する傾向があるため、これを取り上げます。

• 本当に悪いプロジェクト見積もり。再現性係数は非常に低いため、最終的にどれだけ大きくなり、何かを構築するのにどれくらい時間がかかるかを予測することは困難です。プロジェクトマネージャーと管理者がコードに手を触れて実際に何が行われているかを見ることができないことを考えると、タイムラインに関する非現実的な期待が生じます。

• QA / QCは、大規模プロジェクト向けに強調されることはありません。これは、コンポーネント間のインターフェイスが緩くなり、コンポーネントの動作方法に関する厳密な仕様がなくなることに戻ります。そのゆるみは、意図しない結果を引き起こし、バグが忍び込むことを可能にします。

• 一貫して測定可能な資格。一般的に、人々はX言語またはプログラミングで働いた年数について話します。時間は、能力やスキルの質の代わりに使用されています。何度も言及されているように、面接や優れたプログラミングの才能を見つけるのは難しい。問題の一部は、「良い」の定義が非常に主観的なままであることです。

私はすべてが否定的であることを意味するものではありません。ソフトウェア業界は私たちがこれまで行ってきたところから大きく進歩したと思います。このようなフォーラムや他のフォーラムは、設計原則の会話と議論を促進するのに本当に役立ちました。ソフトウェアエンジニア向けの「ベースライン」知識の標準化に取り組んでいる組織があります。確かに改善の余地はありますが、業界はかなり短い期間で大きな進歩を遂げたと思います。

答えは驚くほど簡単です。「他の産業」は故障率が高いのです。私たちは間違ったものを比較しているだけです。ソフトウェアの作成は「ビルド」と呼ばれることが多いため、他の業界の製造段階や建設段階と比較します。しかしそれを見ると、それは構築ではなく、設計です。ソフトウェア設計はコードで記述されており、ソフトウェアのコンパイルまたはその場で直接解釈することによって、構築はコンピューターによって行われます。

他の業界の多くの設計は、当初の予測よりもはるかに長くかかり、コストがかかるか、単に完成することはありません。おなじみの音？

それでは、ソフトウェアを計画しているときに何をしているのでしょうか？まあ、私たちはまだ設計していますが、初期段階です。

ソフトウェアには、注目すべき製造ラインはありません。最終コンポーネントの構築は（比較的）安価であり、その最終製品の複製は完全かつ効果的に無料です。ビルドアーティファクトをコピーします。

いくつかの図を指摘するには：

1. 実装開始後の要件の変更。たとえば、最初のエアバスA380が工場で作成され始めたとき、誰かがさらに200席を欲しければ、そこに置かれるとは信じられません。しかし、プログラマーが開発を開始した後でも、大規模なソフトウェアプロジェクトでは、さらに5種類のユーザーを追加できます。
2. 複雑さ -大規模なソフトウェアプロジェクトは非常に複雑です。おそらく、人類が設計および開発した最も複雑なプロジェクト。
3. アーキテクチャおよび設計段階で十分なリソースが消費されていません。
4. 分野の未熟さ -ソフトウェアエンジニアリングは、他のエンジニアリングの姉妹と比較して比較的若い分野です。これには2つの意味があります。a）ヒューリスティックやグッドプラクティスがそれほど多くない。b）非常に経験のある専門家はそれほど多くない。
5. 数学的証明の欠如 -ほとんどの場合、数個の形式的な方法は、ソフトウェアが必要に応じて機能することを証明するために使用されません。代わりにテストが使用されます。これは、数学に大きく依存している他の工学分野にも当てはまります。その理由は複雑さです。
6. ラッシュ -多くのマネージャーは達成できない期限があります。期限のために、コードの品質が2番目になります。

質問に厳密に答える-私は、他の人がプログラマーから非常に高い期待（特に納期）を持ち、大規模なソフトウェアのプログラミングがいかに難しいかを正確に理解していないと信じがちです。

質問の前提には少し欠陥があります。A380とボーイング787の両方が数年遅れで納入されました。

A380の場合、遅延の多くは、CATIA設計ソフトウェアの異なるわずかに互換性のないバージョンを使用しているエアバスのフランスとドイツのユニットが原因で発生しました。これは、互換性のない形で、飛行機に完全に適合しないワイヤリングハーネスとして現れました。

最も広く使用されている航空機設計ソフトウェアであるCATIAには何も問題はありませんでしたが、誰かがソフトウェア構成ボールを落としました。

ボーイング787もソフトウェア関連の遅延に悩まされていましたが、その問題のほとんどは、重量制御やサプライヤーによる標準以下の部品の配送など、より伝統的な新しい飛行機の問題でした。

A380とB787の両方は、最初の航空機に構造的な問題が発生した後、翼の設計を変更する必要がありました。

大規模で複雑なプロジェクトは、すべての分野の人間にとって困難です。

ここに超高層ビルの男。あなたの質問に答えられるかどうかはわかりませんが、スレッドのさまざまな項目に光を当てることはできます。実際、建物は非常に高速で発生します。主な制約はロケール（規制）です。しかし、一般に、高層ビルの最初から最後まで3〜10年かかります。

新しい建物と新しいソフトウェアプロジェクトを比較するのはあまり正確ではないと思います。新しい建物は、カーネルまたはOSの新しいバージョンに近くなります。この点で、ソフトウェア開発ははるかに高速です。ゼロから構築することはありません。これは、クライアントがサインアップしないリスクの高いタスクになるためです。建物のほとんどの設計と開発は、実績のある完成したプロジェクトの派生物です。

個人的な経験から、これまでに構築されたプロジェクトは10分の1です。プロセスは設計主導型ではなく開発主導型であるため、設計がプロセスの安価なコンポーネントであるため、鉄鋼の価格のようなものがプロジェクト全体で上昇する瞬間は窓の外、つまり設計されます。

設計には、構想から回路図まで1か月、設計開発まで2から6か月、建築家、計画コンサルタント、構造エンジニア、風力エンジニア、サービスエンジニア、数量およびコストコンサルタント、測量士のチームによる詳細および建設文書までさらに6か月かかります。アクセシビリティエンジニアとリストが続きます...

仮想対物理の議論はあまり正確ではありません。また、主に仮想ツールを使用し、さらに、最終製品から時間的および規模的に離れています。ほとんどの場合、モックアップスケールで建物の側面をテストすることさえできず、シミュレーションを使用して、発生する可能性のあるものを予測しようとします。

複雑さに関しては違いがありますが、全体的にはほぼ同じです。相互に関連するユニットと、複数レベルの階層化された抽象化とインターフェースだけでなく、コミュニケーションを非常に困難にするプロセスの小さな部分に非常に専門化されています。

設計対開発の議論に関しては、どちらのプロセスも設計されていると思います。これらを分離しておくのは学問的には素晴らしいことですが、物事の仕組みがわからない場合は設計できません。失敗のリスクを高めるだけです。

全体として、OPの質問による私の（潜在的に間違っている）推定は、プログラミングは工学よりも芸術であるということです。なぜ人々は喜びを味わうだけでなく、無料でそれを行い、その中に表現と優雅さを見つけるのでしょうか？また、コンピューターサイエンスは（錫のように）エンジニアリングというよりも科学です。既存のパーツにパッチを当てるのではなく、アルゴリズムを証明して、機能するように努力するのはなぜですか？これが意味をなすかどうかはわかりません。私はソフトウェアの男ではありません。

ソフトウェアの設計と開発で私を襲った1つの側面は、メディア自体についてです。コンピューターは人間中心の仕事を非常に不自然にします。すべてが非常に明確であり、許容値はほとんどありません。精神的にこれを回避するのは難しく、中には複雑さを捨てることでそれを回避する人もいます。他に何もない場合、これは何か関係があるのでしょうか？

それから、それらの設計にはどれくらい時間がかかりましたか？年？二？10年？デザインは何かを構築する上で最も複雑な部分であり、構築自体は簡単です。

この記事に基づいて、ソフトウェア開発はほとんどが設計プロセスであり、設計文書がソースコードそのものであることが徐々に理解されています。また、設計プロセスは生産プロセスとはまったく異なります。わずかな要件の変更でさえ、プロジェクトの全体的なアーキテクチャに大きな変化をもたらす可能性があるため、経験豊富な人材が必要であり、計画することは不可能です。この理解は、風洞で飛行機モデルをテストするのと同様に、最終設計ドキュメントとしてコード品質を改善し、設計プロセスの一部としてテストとデバッグを行うことに焦点を当てたアジャイル方法論の基礎です。

構築自体はコンパイラによって自動的に処理されます。そのおかげで、数分で製品全体を構築できます。

ソフトウェアプロジェクトが大幅な遅延と高コストで終了する理由は、管理者がそのような設計プロセスを推定、予測、計画できるとまだ考えているためです。これは実際に有効であるよりも頻繁に発生します。彼らは依然として、最終結果がコストの増加と期限の遅れでほとんど反対であるにもかかわらず、人々を厳格な建設プロセスに結び付けることにより、何らかの方法で品質を向上させることができると考えています。

エアバスA380の設計の最中に、誰かが会議でパイプを使い、「それは三葉機として構築できるのか？」と言ったと想像してください。他の参加者は、「うん、そうだ。三葉機。翼が多いほど良い」と言って参加しました。次の3年間は、A380の設計を三葉機に変えることに費やされています。別の会議で、誰かが「三葉機ですか？それは古いです。複葉機が欲しいです。翼の片方を取り除いてください。」と言います。

または、橋の建設プロジェクトの途中で、誰かが「ええ、私たちは海運会社と取り引きをしました。彼らの船はもっと高いので、橋をさらに40フィート高くする必要があります。修正してください。ありがとう。 」

これらは、大小を問わずソフトウェアプロジェクトが驚くべき速度で失敗する理由の一部です。

ITで働いている機械工学のバックグラウンドを持つ人として、ITでの成功率が低い理由についてよく疑問に思いました。

このスレッドの他の人たちと同様に、失敗の原因はITの未熟さ、詳細な標準の欠如（はい、真面目です。単純なボルトの標準シートを確認したことがありますか？）コンポーネントとモジュール。

建物の建設や造船のような他の産業も、はるかに「beatられた道」を持っています。特定のソリューションプロトタイプの知識と経験で、カスタマイズされた形で何度も再利用されます。サイズや目的の異なる建物、船、飛行機がどうして似ているのかと疑問に思ったことはありませんか？（もちろんルールには例外があります...）

これは、これらのプロトタイプが十分に研究され、よく理解され、一般的に使用され、実績があるためです。他の方法でできなかったからではありません。ITにおける標準化はほとんどの場合ではありません：（大）のプロジェクトが同時に研究と配信を行って、コンポーネントを再発明する傾向と同じ人と！

これらは必然的に1回限りの製品につながります。これは、開発とサービスに費用がかかり、エラーが発生しやすく、不確実な条件下では予測不可能な方法で故障します。そして、このため、もちろん、これらの製品はずっと早く廃止され、書き留められ、わずかに優れたものと同等のコストで置き換えられます。ITが必要とするのは、中世の職人を効率的な工場に変えた産業革命に相当するものです。

ただし、ITを本当にユニークなものにしている要因があります。これらの他の言及された産業とは対照的に、ITは真に遍在しています。現代生活のあらゆる側面で使用されています。したがって、ITはこの大きな進歩を達成した小さな奇跡であり、ITが成果を上げることができます。

私はあなたの声明に同意しないことを恐れています。

エアバスとボーイングは、飛行機を製造する会社の2つの例です。飛行機を作る会社はいくつありますか？ソフトウェアを構築する企業の数と比較すると、ごくわずかです。

ソフトウェアプロジェクトをねじ込むのと同じように、飛行機プロジェクトをねじ込むのも簡単です。航空機製造業界の参入障壁がソフトウェア業界と同様に低かった場合、多くの失敗した航空機プロジェクトを確実に目にするでしょう。

車を見てください。非常に耐久性が高く高度な自動車を製造する高品質のメーカーがあり（Land Rover、Mercedesを考えてください）、修理せずに1年も続かない自動車を製造するメーカーがあります（KiaまたはCherryを考えてください）。これは、参入障壁がわずかに低い業界の完璧な例です。これは、プレイヤーが弱くなってきた場合です。

ソフトウェアも同様です。バグの多い製品がたくさんありますが、Windows、Office、Linux、Chrome、またはGoogle Searchは非常に高品質のプロジェクトで、納期どおりに配信され、航空機と同等の品質レベルを備えています。

多くの人々が見逃している他のポイントは、私たちが人生の事実としてとっている車、タンカー、または航空機のメンテナンスにどれだけのメンテナンスが費やされているかです。すべての飛行機は、離陸する前に技術的な検査を受ける必要があります。数キロのマイルごとに車を点検し、オイル交換、タイヤ交換などの定期的な点検を行う必要があります。

ソフトウェアにもそれが必要です。機械/物理製品と同様に、診断、防止、またはソフトウェアの状態と品質の監査に多くの時間を費やした人だけがいるとしたら、こうした声明はもっと少なくなると思います。アプリケーションを起動する前に毎回アプリケーションのログを読みますか？まあ..それが航空機だったら、あなたはしなければならないでしょう;-)

デジタルビルディングブロックには1または0を指定できます。間にはありません。

機械設計にはある程度の許容度があります。完全ではないリベットをブリッジに1つ入れることができますが、ほとんどの場合、コード内で1が必要な場所に0を置くだけでもプログラム全体が失敗する可能性があります。

コンピューティングの論理的かつインタラクティブな性質により、ごくわずかな変更でも、重大な障害につながる可能性があります。

私はしばしば同じことを疑問に思っています。私たちが何をしているのかまったくわからないアマチュアの束のように感じることは確かです。私はマネージャーやその他の外部要因を非難する説明を嫌います。私たちの開発者は私たちが作成したものに責任を持つべきです。

私たちはエラーが安いビジネスにいると思います。超高層ビルを再構築したり、販売されているすべての携帯電話を思い出したりするのに比べて、ソフトウェアにパッチを当てるのは安価です。

これはバグが日常生活の一部である文化を作成しました。彼らは肩をすくめて受け入れます。いくつかのバグはおそらく避けられないかもしれませんが、それらは日々の仕事を支配すべきでしょうか？とにかくバグを期待しているからこそ、QAがトラブルの価値があると感じないマネージャーを完全に理解しています。バグを修正するのはつまらないので、エラーのないコードを作成するために全力を尽くさないプログラマーは理解できません。

本質的に私はそれが文化の問題であると信じており、それが変わることを願っています。

エンジニアリングの標準と実践は、IT（独立した産業）と航空宇宙では非常に異なります。これはおそらく、航空宇宙でITの標準文書に遭遇したときにIT専門家がどのように反応するかを考慮することで最も簡単に理解できます。たとえば、最近インターネットに登場したジョイントストライクファイターC ++標準。

多くの人が娯楽や物欲的な辞任を表明します（そうすればいいのですが）。そして、多くの人がrid笑で対応し、このように消費者向け製品を提供する実用的な方法はないと主張しています。消費者の期待ではなく、経営者の期待を考えれば、これも正しいかもしれません。何もデモをせずに、ほんの数週間コーディングしてコーディングするコーダーには、大きな不信感があります。神は、2週間だけ何かをデザインするコーダーを助けます。飛行機ではそうではありません。

ソフトウェアでは、人々は本当に何かを今すぐに期待しています。確かに、推論が進むと、それを本当にしっかりさせるには少し時間がかかります。しかし、1週間で複雑なことを簡単な言葉で説明することはできませんか？また、正直で複雑な用語で記述された複雑なものは、想像力を刺激することはめったにないことを学びます。したがって、多くのエンジニアは、創造的な方法で組み立てられた本当にシンプルなものの想像された世界に共謀することになります（難しいものの世界が本当にうまく行われるのに対して）。

私からいくつかのもの：

1-標準と部品：それらは飛行機メーカーであり、開発者ではありません。よくわかりませんが、多くの部品が外部委託されていると思います。彼らは独自の電子機器を構築せず、ある会社から座席を取得し、エンジンはおそらく他の場所で開発されます。

一方、ソフトウェアプロジェクトは、ほとんどの場合、いくつかの小さなフレームワーク/ヘルパーのみを使用してゼロから開始します。

2-市場投入までの時間：飛行機にとって時間は重要な問題ではありません。エアバスの設計は、完成する何年も前に確定し、その間に起こる可能性のある大きなブレークスルーを無視することを選択したに違いありません。（たとえば、自動車メーカーと同じですが、現在開発している最先端の技術は、5〜10年後には市場に出回るでしょう。）

ソフトウェアについては、非常に機敏である必要があります。巨大なプロジェクトを今すぐ開始し、変更せずに開発するのに3年かかる場合、もう利用できない技術に頼っている可能性が非常に高いか、製品が完全に古くなっています。これにより、多くの問題が発生します。

3-リリースサイクルとバージョン。-飛行機は「解放」されたときに完全に完成する必要があります。安定したベータバージョン、ナイトリービルドなどはありません。さらに、一度完了すると、小さな方法でしか変更できません。既存のボーイングに100席のレベルを追加することはできません。それは不可能です。

一方、ソフトウェアには漸進的な変更があり、多くの場合、「機能するビルド」ですが、必ずしも完成した製品ではありません。また、ITでは「飛行機にさらに50トンの荷物を入れる別の荷物室を追加しましょう」と言うのは珍しいことではありません。

答えは非常に簡単だと思います：

1）物理的な構築と実装は、人々がいる限り存在します-物理プロジェクトを実装するための方法と技術を開発するのに何千年もかかりました。まったく新しい異なるスキルセットを必要とするソフトウェアの「構築」は、50年以上も前のものではありません。まだ十分に理解できていません。

2）仮想構築はより困難です-物理的な現実がまったくないことを心の中に「見る」必要があります。製品がどのようなものであるか、そして製品を作成するために必要な手順を知る前に、多くの情報を分析して抽象化する必要があります。橋や建物を建てるときはそうではありません。

3）多くの場合、ソフトウェアの障害やバグの原因を見つけることは、物理的なエンジニアリングを行う場合よりもはるかに困難です。桁が座屈する場合、座屈する場所がわかり、それを支えて失敗するなどのサポートが表示されます。物理構造のように物理学と数学の法則。

Jack Ganssleの埋め込みミューズからの記事の逐語的なコピーを使用して答えてみます。これはどこでもファームウェアを意味しますが、精神的にソフトウェアに置き換えてください。

何と比較して？

ファームウェアは、世界で最も高価なものです。ロッキード・マーティンの前CEOであるノーマン・オーガスティンは、彼のすばらしい本「アウグスティヌスの法則」で、防衛コミュニティが遭遇した問題について明らかにする物語を語っています。高性能戦闘機は、燃料範囲と性能の相反するニーズの微妙なバランスです。速度対重量。70年代後半には、戦闘機はかつてないほど重くなっていたようです。常により大きな利益を追求している請負業者は、コストを大幅に追加できるものの、重さは何もありませんでした。

答え：ファームウェア。無限のコスト、質量ゼロ。現在、アビオニクスは戦闘機のコストの半分以上を占めています。最新のアメリカの戦闘機であるF-22を考えると、それは大きな変化です。アウグスティヌスは、彼がこの物語を語るとき、ほんとうに歓喜を唱えます。

しかし、なぜソフトウェアはそんなに高価なのでしょうか？トム・デマルコはかつてこの3つの言葉でこの質問に答えました：何と比較して？彼は比較的退屈なビジネスケースについて話し合いましたが、その答えは長年私の心に響きました。何と比較して？ソフトウェアを使用して、前例のない複雑さの製品動作を定期的に作成します。確かに、コードは高価です。しかし、文明の歴史上、これほど複雑なものを構築した人はいません。

ウィキペディアから恥知らずに持ち上げられ、正確性がチェックされていない、次のバブルソートを検討してください。

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

おそらく110時間の非スペース文字であり、おそらく1〜2時間で放り出されます。ソフトウェアがなく、他の戦略を使用してソートを実装する必要があったとします。費用はいくらですか？

機械技術者は、彼の職業がコンピューターよりずっと前にソーターを作ったことを自慢するかもしれません。IBMの1949年モデル82カードソーター（http://www.columbia.edu/acis/history/sorter.html）を検討してください。スループットは毎分650カードであり、コードスニペットが4 MHzでも管理できない場合があります。 Z80。モデル82は、もちろん、一度にカードの1列のみをソートしました。デッキを完全にソートするには、数十回のパスが必要です。

この獣を設計し、構築するのにどれくらい時間がかかりましたか？年、間違いなく。また、非常に高速で巨大なデータセットを処理できるコードと比較すると、その機能は劣っています。しかし、それは1949年でした。FPGAとVHDL、またはCPUなしで、電子部品からバブルソートを作成するのにどれくらい時間がかかりますか？

1時間で、チップレベルの1つ上の大まかなブロック図を管理しました（ブロックには「加算器」、「16ビットラッチ」などの名前が付いています）。しかし、シーケンスロジックは明らかにかなり乱雑であるため、適切な方程式を書くことはそれほど難しくないと仮定して、PLDに放り込みました。そして、はい、おそらくそれはプログラマブルロジックのルールを破りますが、合理的な時間内にゲートを使用してすべてのロジックを設計およびデバッグすることは、1ガロンのガスと同じくらいありそうにありません。

16ビットのワードとアドレスを想定すると、回路には約12個の16ビットラッチ、加算器などが必要になります。プラスメモリ。また、ソートされていないデータがRAMにどのように到着するか、結果がどのようにエクスポートされるかについてもわかりません。これらは不特定の設計要件です。ソフトウェアのみのソリューションでは、関数プロトタイプを書くだけでこれらの要件が自然に解決されます。

大まかなブロック図を回路図に変換するのに1日かかる場合があります。次に、PCBの設計と製造、部品の注文とロード（および予期しないが避けられない寿命末期の問題に対処するための設計の変更）、そしてもちろん回路を動作させる時間があります。数週間の努力と、ボード、部品、および適切なテスト機器のための多額のお金を話すことができました。

これはすべて、7行のコードを置き換えるためのものです。10,000未満の実際の組み込みプログラムはほとんどありません。多くは百万を超えています。実際の超大型コンピュータープログラムを置き換えるには、どのくらいのハードウェアとエンジニアリングが必要ですか？

スプレッドシートのような実際のプログラムを考えてみましょう。プロセッサなしで回路を作成するには、どのくらいの回路が必要ですか？それは都市の大きさかもしれません。

ファームウェアは世界で最も高価なものですが、それは解決する問題の想像を絶する複雑さのためです。しかし、それは他の選択肢よりもはるかに安いです。そのため、上司がソフトウェアにこれほど時間がかかる理由をいらいらせずに尋ねると、何を言うべきかがわかります。 何と比較して？

だから！ソフトウェア/ファームウェアには比類のない複雑さがあります。

ソフトウェアのエンジニアリングと管理は、他の多くのエンジニアリング分野と根本的に異なります。成果物は物理的なものではなく、生産プロセスは設計および開発プロセスです。ソフトウェアの別のコピーを作成すると、限界費用は本質的にゼロになります。すべてのコストは、最初のコピーの開発にあります。

規律としてのソフトウェアエンジニアリングと管理の相対的な若さのため、ソフトウェア開発とエンジニアリング全体を妨げる事実として誤解と誤解が残っています（このリファレンスを参照）。

すべての開発者が平等に作成されるわけではありません。良いものもあれば、そうでないものもあります。

いつも他の人のコードを読んで、私が言っていることを感じてみてください。余分な論理ステートメントが多すぎると、リスクが増える可能性があります。これらのリスクは、悪い行動やバグにつながる可能性があります。論理ステートメントが不足しているため、null参照があります。優れたプログラマーはこれを理解し、いつどこで何をすべきかを知っています。しかし、誰も完璧ではありません。物事は複雑です。よく考えられていない他の人の作業を追加すると、プロジェクトがどのように実行されるかを簡単に確認できます。

大聖堂の建設には、最大100年かかりました。

一部のエアバス機では、100万行のコードが必要です。

何かを改善する時間が長くなればなるほど、より多くの改善が得られるので、ソフトウェア業界に数世紀の試行錯誤を加えて改善してください。または欠陥。

大規模なプロジェクトは、大規模な組織で頻繁に発生します。大規模な組織で働いたことがない場合、パフォーマンスと生産性を損なうことが保証されていることが1つあります。それは官僚主義です。

驚くべきことに、多くの人々は官僚制度が何であるか（しばしば政治と混同されます）、あるいは官僚制度の問題があるかどうかを知りません。

最近、スマートカード認証を実装するプロジェクトを完了しました。当初は3か月と推定されていました。15か月かかりました。遅延の費用、予算、範囲、技術的な理由はありませんでした。スコープは実際にはかなり狭かった-昇格された特権を持つアカウント（管理者アカウント）のみ、合計で約1,200アカウント。

もう1つの重要な要素は、ビジネスパートナーです。これにはベンダーも含まれます。パートナーにプロジェクトの遅延を引き起こす問題がある場合、実際に遅延の問題を解決するオプションは多くありません。彼らはあなたのために直接働きません、そして、あなたは原因であるかもしれないパートナーでその人を解雇できないかもしれません。パートナーは解雇されるか、金銭的罰金または制裁措置の対象となる可能性がありますが、プロジェクトが遅延したという事実は変わりません。これは、ボーイング787ドリームライナーで巨大な調達戦略を引き受けたときにボーイングで発生したものです。

私はあなたのために短いバージョンを持っています：

簡単に、または合理化できるものは何でも、私たちの代わりにそれを行うプログラムを作成します。

そして、代わりにメタプロセスと戦います。

それ自体はそれほど真実ではありませんが、ブログエンジンを書く代わりに、毎日何千ものブログが設定されています。毎日仕事をするために、特別に設計されたデータベースアプリケーションを記述する代わりに、数千のExcelマクロが書き込まれます。

他にも多くの要因があります-それらのいくつかはここで言及しました-しかし、私は議論にこの点を加えたかったです。

説明責任の欠如...航空機がcrash落すると人々は訴えられます。ソフトウェア業界は、ソフトウェアの欠陥に対する責任を負いません。そのため、堅牢で安全な製品を作成するインセンティブが失われます。

ほとんどの大規模なプロジェクトでは、サブプロジェクトの分離度が高く、少数の設計制約を定義できます。これらのサブプロジェクトがそれぞれ完了すると、プロジェクト全体が機能します。サブプロジェクトで何か問題が発生した場合、すべての努力は問題になりません。サブプロジェクトを完了する別の方法を探すだけです（たとえば、別のエンジンを使用する）。

これは可能ですが、ソフトウェアプロジェクトでは実際的にも人間性の問題としても困難です。

一部では、他の業界は、この種の分離可能性が良いことであるという難しい方法を学んでいます。たとえば、ロールスロイスの航空機エンジンを使用する場合、特定のデザインの翼でのみ機能する特別なロールスロイスのボルトと取り付け点を使用する必要はありません。その後、プラットとホイットニーに切り替えようとすると、翼全体をゼロから再設計する必要があります（そのため、胴体の完全な再設計が必要になり、そのために別の座席を購入する必要があり、その結果、別の機内エンターテイメントシステムを購入する必要があります）これ...）。いくつかのリンケージが存在する可能性があります-注意せずにエンジンを交換することはできませんが、大規模なプロジェクトは一般に、そのようなことが最小限に抑えられている場合にうまく機能します。

大きなプロジェクトが小さなプロジェクトのクラスターによって実際に解決される限り、互いにきれいなインターフェースを持つ小さなソフトウェアプロジェクトのクラスターとして設計された大きなソフトウェアプロジェクトは、特に頻繁に失敗することはありません。（この点について間違える可能性があります。）

ソフトウェアシステムの構築は、物理構造の構築とは大きく異なります。つまり、実装は大きく異なります。たとえば、巨大なタンカーを構築している間、ロボットまたは手でパーツを一緒に溶接したり、すべてのナットとボルトを締めたり、塗装したり、すべてを持ち込んで装飾を行うなど、比較的単純な（しかし簡単ではありません！）機器や家具など。これはすべて、本当に簡単なことです。

ただし、ソフトウェアに関しては、はるかに複雑になります。たとえば、製品の一部を保存する安全なログインとユーザー資格情報をどのように正確に実装しますか？どのライブラリとツールを使用できますか？どのライブラリとツールを使い慣れていますか？ハッシュ関数とソルティング関数をどのように正確に記述し、それが安全であることをどのように確認しますか？これは非常に多くの方法で行うことができるため、これらの種類の実際の実用的なデザインパターンを設定することは不可能です。はい、前述のデザインパターンは「ベストプラクティス」として小規模に存在しますが、すべてのソフトウェアシステムは他のシステムとは大きく異なり、フィールドは非常に速いペースで進歩および変化するため、維持することは本質的に不可能です。

家を建てるとき、メインの支持壁が不適切で交換が必要であると気づくような問題に実際に遭遇することはありません。これまでの進捗を解体し、支持壁をやり直してベースから始める必要があります。設計段階でこのような問題に取り組むのは、建物に必要なサポートウォールの種類を予測するのが比較的簡単だからです。

ただし、ソフトウェアの場合はそうではありません。製品全体を単一のエンティティとして実際に設計してから実装することはできません。通常、ソフトウェア設計プロセスは反復的であり、目標と要件は製品の実装とテストに応じて変化します。ソフトウェア開発は全体として反復プロセスであり、通常は予想以上に物事が変化しますが、そのような変化は多くの場合、より多くの作業、複雑さ、そして残念ながら最終的にはより多くのお金、時間、ハードワークを必要とする課題を課します。

したがって、本質的に、大きなプロジェクトを提供し、プロジェクトのタイムラインとロードマップを見積もることが難しい理由は、ソフトウェア開発と特に実用的な設計が非常に複雑な分野だからです。複雑さが根本的な問題です。

「大規模プロジェクト」の定義は歪んでいます。

技術的には、大規模なプロジェクトは期日通りに配信でき、何年にもわたって何度も何度も構築されてきたものであると認められています。

• パックマンクローン。
• 電卓
• テキストエディター

きっとあなたは考えているに違いありません... "しかし、これらは小さなプロジェクトです！テキストエディタはシンプルです。" 私はあなたに同意しません。コンピューターはとてつもなく複雑です。オペレーティングシステムにユーザーをインストールして設定するだけでは困難な場合があり、OSの記述やハードウェアの構築さえしていません。

あなたが話しているプロジェクトは、宇宙探査に似た巨大なプロジェクトです。銀河間旅行を開発するのにどれくらい時間がかかるかをどのように知っていますか？どのモデルに基づいていますか？既知の既知、未知の未知、未知の未知、そして最後に未知の未知があり、これらはたまたまソフトウェア開発で登場します。

問題は期待のひとつだと思います。テクノロジーが存在するからといって、しばらく使用しても成功する（または使用するのが賢明）とは限りません。他の産業がソフトウェア産業と同じように振る舞うなら、10年の終わりまでにブラックホール駆動の掃除機を販売することになります。または、一部の「ビジョン」には月面基地を構築するためのリソースがあり、スターバックスは訪問者の体験を実際に「概算する」と判断します。私は問題がソフトウェア業界だとは思わないが、期待されている。

言及できるのはそれだけではありませんが、1つの基本的なことは指摘する価値があると思います。ほとんどの製品は、既存の動作に適合することを目的としています。急進的なブレークスルーの製品（自動車など）でさえ、一般に既存の動作に適合するように構築されており、それを少し簡単/簡単/安く/何でもできるようにします。はい、多くの場合、既存の行動にもいくつかの副作用があります（たとえば、馬の餌の代わりに車の燃料を得る）が、後者のほとんどはかなり軽度の副作用である傾向があります。

対照的に、ユーザーの行動を変えない（たとえば、仕事をかなり簡単にする）ほとんどすべてのソフトウェアは、基本的に1日目から完全に失敗することが保証されています。さらに悪いことに、大規模なソフトウェアプロジェクトは、個々のレベルでのユーザーの行動が含まれますが、大規模なグループ（多くの場合は組織全体）の行動が含まれます。

要するに、多くの場合、ソフトウェア自体の設計が仕事の最も簡単な部分です。難しいのは、彼らのために人々の仕事を再設計することです。それを始めるのは難しいです。うまく機能するだけでなく、受け入れられるような方法でそれを行うことは、依然としてはるかに困難です。

あなたが言及したように、エアバスA380は成功したプロジェクトではありませんでした。私はたまたまCAD / CAM会社で働いており、会社ごとに異なるバージョンのソフトウェアを使用していたため、それ（Airbusのプロジェクトもありました）が数年遅れたと言われました。つまり、世界のさまざまな部分でさまざまなパーツが設計されていました。そして、統合中に、彼らはすべての設計が統合されないことを知ったので、彼らは1つのバージョンでそれを再設計しなければなりません。それを見て、私はそれが成功したとは思わない。2〜3年前なら、エアバスのゲームチェンジャーだったでしょう。

また、堅牢なソフトウェアに関しては、飛行機、車（ABS、EPS、気候制御など）またはスペースシャトルを見ると、50％以上のソフトウェアが実行されており、非常に堅牢です。私たちがソフトウェアにもっと近づいているというだけで、さらに多くのソフトウェアプログラムがあるので、エラーが多くなっています。

訪問：http://www.globalprojectstrategy.com/lessons/case.php?id=23 とエアバスA380だったどのくらい成功ご覧ください。

ここでは、エンジニアリングのバックグラウンドを持つソフトウェアエンジニアと、建設業で働く妻がいます。私たちは仕事の違いについて長い議論を重ねてきました。

ソフトウェアエンジニアリングとは新しいものを設計することです。基本的なほとんどすべては、どこかのオープンソースライブラリで行われています。ソフトウェアエンジニアが雇用されるほとんどすべての仕事で、彼女は存在しないものを設計する必要があります。

建設やエンジニアリングのほとんどの形式のようなものでは、ソフトウェアの「ライブラリ」にあるものはすでに完全に設計されています。塔を建てたいですか？いくつかの変更を加えて、既存の構造から計画をコピーして貼り付けてください。

実際、私がエンジニアにならないことに決めた主な理由の1つは、既存の発明に対して10％の改善を設計するのにほとんどの時間を費やしていることです。 。

エンジニアリングには多くの新しいデザインはありません。非常に熟練したエンジニアとは、既存の設計を操作して新しいものを作成したり、改善したりできる人のことです。しかし、ほとんどすべてのプログラマーは、設計を変更したり、それらをハックしたり、新しいものを作成したりすることが期待されています。

アセンブリからC、C ++、Java、JavaScript、C＃、PHPなどまで、標準がどれだけ完全に変わったかを振り返ってください。10年または20年前からリサイクルできるコードは多くありません。これは、自動車産業や航空産業では何十年も前から設計を改善し続けることができると言うのとはまったく異なります。

プロジェクトの管理はソフトウェアで難しいことで有名です。時間の見積もりは、作業を行う人々によって最もよく行われますが、見積もりの​​作成に忙しいときは、コードを書いていません。これにより、人々はプロジェクト管理を一切避けようとします。

多くの場合、多くのコードは特定の人に依存しており、これらの人が遅れたり実行できない場合、コードは先に進みません。対照的に、車を作りたい場合は、タイヤ、シャーシ、バッテリー、エンジンなどを組み立てるために、さまざまな人を単に雇うことができます。オブジェクト指向および既存のフレームワークによりこれが可能になりますが、すべてをゼロから設計する場合には実用的ではない場合があります。

失敗はソフトウェアで許可される場合があります。テストには費用がかかる場合があります。ソフトウェアでは、クラッシュを修正することができる場合、すべてのテストをスキップするのは非常に魅力的です。エンジニアリングのほとんどの形態では、「クラッシュ」は致命的です。

極端なプログラミング（実際にはソフトウェアメガプロジェクトで使用されていた）など、広範なテストを使用するプログラミング方法があります。しかし、締め切りが厳しくなっているため（意図的に厳しくすることができます）、プログラミングをすべてスキップしてバグを抱えて起動するのは魅力的です。「常にすべてのバグを修正する」というJoel Spolskyスタイルは、長い目で見ればより多くの時間を節約しますが、規律のない人はこれをスキップして失敗します。

小さなプロジェクトの方が良い。私の妻はかつて私に大企業で仕事をするように頼みました。大企業は悪い会社だという議論になりました...彼女にとって、大企業は多くのリソース、経験、機能的なプロジェクト管理、適切な手順を持っていました。私にとって、大企業とは恐竜であり、コードの修正、テスト、ドキュメントの作成にほとんどの時間を費やしています。

私は10人未満で100万ドルのITプロジェクトに取り組んできました。より多くの人々がプロジェクトを遅くし、不必要な官僚主義を加えていただろう。WhatsAppは、数十億ドルの価値がある「小さな」プロジェクトの例です。大規模なプロジェクトが不可能というわけではありませんが、ソフトウェアで何十億ドルもの価値を生み出すために何千人もの人々を必要としないのです。

他の質問で実際に取り上げられていない理由の1つは、ソフトウェアの分野がマテリアルベースの世界ではめったに発生しないスピードで革新することです。

その理由の1つは、ソフトウェア（プログラミング言語、ビルドツール、IDE）がソフトウェアのビルドに使用されるため、ソフトウェアの進化は正のフィードバックサイクルであることです。これは、リターンを加速するレイカーツワイルの法則の最も明らかな例であり、指数関数的に成長する速度で進歩を遂げます。あなたは1つのフレームワーク、プログラミング言語、通信プロトコルをマスターしたら、それはだ上で移動する時間の横に。

飛行機がソフトウェアのように構築された場合、他のすべてのモデルで材料を変更し、18か月ごとに能力と速度を2倍にし、新しいモデルごとにエンジンテクノロジーを発明したばかりのものに置き換え、水泳や地球外生物を検索する機能を追加します生活。

ああ、そして理想的には、音声コマンドを聞いて、完全に没入型の映画館、ペイントボールアリーナ、そして仕事の旅行が終わると暗い部屋のあるナイトクラブを兼ねます。同じこと！（AからBに確実に移動できる飛行機を製造した会社は、映画館、ペイントボール、ナイトクラブ機能を備えた飛行機が登場してから1年後には腹を立てました。）

私にとって、ソフトウェアエンジニアリングが直面する主な問題は、ユースケース、ユーザー、クロスプラットフォームです。

ユースケース

飛行機にはいくつのユースケースがありますか？そのほとんどは、ある場所から別の場所に飛ぶだけです。レーダー、交通管制などのようなものがあるかもしれませんが、ユースケースは明確であまり多くありません。ソフトウェアエンジニアリングでは、不明確な要件と、自分が望むものを知らないユーザーに直面しています。ユーザーごとに異なる設定/フローが必要ですが、ユーザーが望むように飛行機をカスタマイズできますか（テレビと冷蔵庫が欲しい！）？

ユーザー

誰が飛行機を操作しますか？パイロット、副操縦士、スチュワード（数えられる場合）およびタワーオペレーター。彼らはすべてプロであり、職務内容が明確です。ソフトウェアは、悪意のあるハッカーやクラッカーはもちろん、初心者やダミーによって使用されますが、他のモジュール（OpenIDやGoogle AdSenseなど）と統合可能である必要があります。ミサイルや忍者強盗に耐えながらダミーで飛行機を操作できる場合、飛行機はソフトウェアと同じ品質であると言えます。

クロスプラットフォーム

飛行機は地球の空を飛ぶだけです。霧や風の強い気候、暑くて寒くて湿度の高い気候をどのように処理するのかはわかりませんが、飛行機は異なる重力レベルで飛行するようには設計されていません（火星に飛ぶことができれば驚かされます）。時々 、アプリケーションは、Internet Explorerの、などの異なるプラットフォーム、存続しなければならないGoogle Chromeの、FirefoxのとSafariのブラウザのために（すみませんオペラ OSレベルの場合）、またはWindows XP / 7月8日、またはLinuxを。モバイルデバイスと異なる解像度と向きは言うまでもありません。

他の産業が問題なくプロジェクトを完了すると思う場合は、1977年に建設されたシティグループセンターの建物についてのストーリーをお読みください。7年近くの計画と建設の後でも、建物は深刻な設計欠陥で完成しました。 16年ごとに予想される暴風雨。

つまり、シティコープセンターが毎年立っていたため、16分の1の確率で崩壊する可能性がありました。

元のデザイナーは問題に気づいていませんでしたが、幸いなことに、それは建物を勉強している学生に捕まりました。

LeMessurierが言うように、彼は電話を受けました。LeMessurierによると、1978年に建築学部の学生が彼に、LeMessurierの建物についての大胆な主張で、シティコープセンターが風で吹き飛ぶ可能性があると連絡しました。

修理は文字通り夜間に行われ、設計上の欠陥の機密性を維持するために最少の人数で行われました。

建物を囲む半径10ブロックの緊急避難計画が準備されました。

ビルの居住者が仕事に戻ったように、彼らは夜通し溶接し、夜明けに終了しました。

物語は、作家ジョー・モーゲンシュテルンがパーティーで語られるのを耳にし、ルメスリエにインタビューするまで秘密のままでした。モルゲンシュテルンは、1995年にThe New Yorkerの物語を破りました。

疑問を提起します。プロジェクトのその他の致命的な設計上の欠陥が、公の承認なしに密かに修復または無視された件数。

• ニューヨークの超高層ビルをほぼ一掃した設計上の欠陥（slate.com）
• シティグループセンター（wikipedia.com）