IT業界が他の業界のように大規模で欠陥のないプロジェクトを迅速に提供できないのはなぜですか？
ナショナルジオグラフィックの MegaStructuresシリーズ を見て、大規模なプロジェクトがどれだけ早く完成するかを知りました。準備作業（設計、仕様など）が紙で行われると、巨大プロジェクトの実現自体は数年または場合によっては数か月かかります。
たとえば、 Airbus A38"正式に2000年12月19日に発売"、および "2005年3月上旬" の場合、航空機はすでにテスト済みです。巨大なタンカーや高層ビルなども同様です。
これをソフトウェア業界の遅延と比較すると、なぜほとんどのITプロジェクトが非常に遅いのか、正確には、十分な数の人がいるのに、同じ規模でそれほど速くて問題がないわけがないのか疑問に思わずにはいられません。
エアバスA380などのプロジェクトには、次の両方が含まれます。
主要な予期せぬリスク：これは最初に製造された航空機ではありませんが、それでもテクノロジーの限界を押し上げており、物理的な制約により、小さい旅客機でうまく機能したものは大きい飛行機では機能しない可能性があります。同様に、たとえば、ボーイング747が完成した1969年には利用できなかったため、まだ使用されていない新技術が使用されています。
人的資源および管理全般に関するリスク：プロジェクトの途中で辞めた人、休暇中のため連絡が取れない人、通常の人的ミスなど。
これらのリスクがあるため、人々は非常に短い期間でこれらの大型旅客機のようなプロジェクトを達成しています。配信の遅延にもかかわらず、これらのプロジェクトは依然として非常に成功していますそして高品質の。
ソフトウェア開発に関して言えば、プロジェクトは旅客機ほど（技術的にも管理面でも）大規模で複雑なものではなく、現実世界からの予期せぬリスクはわずかです。
それでも、ほとんどのITプロジェクトは遅くて遅く、プロジェクトにさらに開発者を追加することは解決策ではありません（10人の開発者のチームから2000人のチームへ）プロジェクトをより速く提供できる場合もあれば、そうでない場合もあり、プロジェクトに害を及ぼすだけで、プロジェクトがまったく完了しないリスクが高まる場合もあります）。
まだ配信されているものには、多くのバグが含まれている可能性があり、連続したサービスパックと定期的な更新が必要です（すべてのAirbus A380に「更新のインストール」を2回実行することを想像してください）元の製品のバグにパッチを適用し、航空機のクラッシュを防ぐための週）。
そのような違いはどのように説明できますかソフトウェア開発業界は若くて1つのプロジェクトで何千人もの人々を管理できず、大規模でほぼ欠陥のない製品を非常に高速に提供できないという事実だけが原因ですか？
Ed YourdonのDeath March は、これらのメタタイプの質問のいくつかに触れています。
一般に、ソフトウェア業界には、大規模なプロジェクトの邪魔になる以下の多くが欠けています。
標準化と作業項目の内訳。
- これは確かに良くなっていますが、大きなシステムを作り出すための設計構成はまだありません。いくつかの点で、ソフトウェアは、特定のプロジェクトに必要なものに同意できず、物事をコンポーネントに分解することができません。
- 航空宇宙、建物の建設、自動車などはすべて、完全に並行した開発を可能にするために適度にタイトなインターフェースを備えた非常にコンポーネント駆動のアーキテクチャを備えています。ソフトウェアでは、対応する領域でのブリードスルーが多すぎます。
成功した類似プロジェクトの大部分。 A380は Airbus が最初に作った大きな飛行機ではありませんでした。大規模なソフトウェアアプリケーションは多数存在しますが、それらの多くは何らかの面で劇的な被害を受けており、「成功」とは言えません。
多くの類似した成功したプロジェクトに取り組んだデザイナーとビルダーの大規模な団体。成功したプロジェクトの問題に関連していて、そこに行った人間の才能がないため、再現性の観点から非常に困難になっています。
同じものを2回「構築しない」。多くの点で、飛行機は他の飛行機と同じです。翼、エンジン、座席などがあります。大規模なソフトウェアプロジェクトが繰り返されることはほとんどありません。各OSカーネルは大きく異なります。ファイルシステムの違いを見てください。さらに言えば、本当にユニークなOSはいくつありますか？大きなものは、ある時点でベースアイテムのクローンになります。 [〜＃〜] aix [〜＃〜] 、 Solaris 、 HP-UX 、... AT＆TシステムV 。 Windowsは、各反復を通して信じられないほどの量の前進を示しました。 Linuxのバリアントは一般に、すべてLinusが開始したのと同じコアに戻ります。バリアントは真にユニークな独自仕様のOSよりも速く伝播する傾向があるためです。
本当に悪いプロジェクト見積もり。再現性係数が非常に低いため、最終的にどれくらいの大きさになるか、および何かを構築するのにかかる時間を予測することは困難です。プロジェクトマネージャーと管理者がコードに手を入れて実際に何が行われているかを確認できない場合、タイムラインに関する非現実的な期待が生まれます。
QA/QCは、大規模なプロジェクトの場合ほどには強調されていません。これは、コンポーネント間のインターフェースが緩くなり、コンポーネントの動作について厳密な仕様がないことに戻ります。その緩みにより、意図しない結果が生じ、バグが侵入する可能性があります。
一貫して測定可能な資格。一般に、人々はX言語またはプログラミングで働いた年数について話します。時間は、口径やスキルの質の代わりに使用されています。以前に何度も言及されているように、面接して優れたプログラミングの才能を見つけることは困難です。問題の一部は、「良い」の定義が依然として非常に主観的であるということです。
私はすべて否定的であるという意味ではなく、ソフトウェア業界はこれまでのところから大きな進歩を遂げたと思います。このようなフォーラムや他のフォーラムは、設計原則の会話と議論を促進するのに本当に役立ちました。ソフトウェアエンジニアの「ベースライン」知識の標準化に取り組んでいる組織があります。確かに改善の余地はありますが、業界はかなり短期間で大きな進歩を遂げたと思います。
答えは驚くほど簡単です。それらの「他の産業」doは高い失敗率を持っています。間違ったものを比較しているだけです。ソフトウェアの作成は「ビルド」と呼ばれることが多いため、他の業界の製造または建設フェーズと比較します。しかし、それを見ると、それはまったく構築ではありません。それはdesignです。ソフトウェアの設計はコードで記述されており、ソフトウェアをコンパイルするか、オンザフライで直接解釈するかを問わず、コンピューターで構築されます。
他の業界の多くの設計は、最初に見積もられたよりも時間がかかるか、コストがかかるか、または単に完了しないだけです。聞き覚えがある？
それで、ソフトウェアを計画しているとき、私たちは何をしていますか？まあ、私たちはまだ設計中ですが、初期の段階です。
ソフトウェアには、特筆すべき製造ラインはありません。最終コンポーネントのビルドは（比較的）安価であり、その最終製品の複製は完璧であり、事実上無料です。ビルドアーティファクトをコピーします。
いくつかの数字を指摘するには：
- 実装開始後の要件の変更;たとえば、最初のエアバスA380が工場で作成され始めたとき、誰かがさらに200席を希望した場合、それらがそこに配置されるとは信じられません。しかし、大規模なソフトウェアプロジェクトでは、プログラマが開発を開始した後でも、さらに5種類のユーザーを追加できます。
- 複雑さ-大規模なソフトウェアプロジェクトは非常に複雑です。おそらく人間が設計および開発した最も複雑なプロジェクト。
- アーキテクチャと設計フェーズに十分なリソースが消費されていません。
- フィールド未熟-ソフトウェア工学は、他の工学の姉妹と比較して比較的若い分野です。これには2つの意味があります。a）それほど多くのヒューリスティックスとグッドプラクティスではありません。 b）非常に経験豊富な専門家はそれほど多くありません。
- 数学的証明の欠如-ほとんどの場合、数学的形式手法は、ソフトウェアが必要に応じて機能することを証明するために使用されません。代わりにテストが使用されます。これは、数学に大きく依存する他の工学分野にも当てはまります。この理由は、複雑さです。
- ラッシュ-多くのマネージャーには達成不可能な期限があります。したがって、締切のため、コードの品質は2番目になります。
質問に厳密に答える-他の人はプログラマーから（特に納期に関して）非常に高い期待を持っており、大規模なソフトウェアのプログラミングがどれほど難しいかを正確に理解していないと思いがちです。
質問の前提は少し欠陥があります。 A380とボーイング787はどちらも数年遅れて納品されました。
A380の場合、遅延の多くは、エアバスのフランスとドイツのユニットが 異なる、わずかに互換性のないバージョンのCATIA 設計ソフトウェアを使用したことが原因でした。これは、飛行機に完全には適合しないワイヤリングハーネスとして非互換に現れました。
最も広く使用されている航空機設計ソフトウェアであるCATIAには何の問題もありませんでしたが、誰かがソフトウェア構成のボールを落としました。
ボーイング787にもソフトウェア関連の遅延がありましたが、その問題のほとんどは、重量管理やサプライヤーによる標準以下の部品の配送など、従来の新しい飛行機の問題でした。
A380とB787の両方は、最初の航空機に構造上の問題があった後、翼の設計を変更する必要がありました。
大規模で複雑なプロジェクトは、すべての分野で人間にとって困難です。
超高層ビルの男。私があなたの質問に答えられるかどうかわかりませんが、確かにスレッド内のさまざまなアイテムにいくつかの光を当てることができます。建物は実際に非常に速く発生します。主な制約はロケール（規制）です。しかし、一般的に高層建築物は最初から最後まで3〜10年かかります。
新しい建物と新しいソフトウェアプロジェクトを比較することは、あまり正確ではないと思います。新しい建物は、カーネルまたはOSの新しいバージョンに近いです。この点で、ソフトウェア開発ははるかに高速です。これはクライアントがサインアップすることのない高リスクのタスクになるため、ゼロから構築することはありません。建物のほとんどの設計と開発は、実績のある完成したプロジェクトの派生物です。
個人的な経験から、これまでに構築されたプロジェクトの10分の1のみです。プロセスは設計主導ではなく、開発主導です。そのため、設計がプロセスの安価なコンポーネントであるため、鉄鋼の価格のようなものがプロジェクト全体で上昇する瞬間は、窓の外、つまり設計されています。
設計には、概念図から回路図まで2か月、設計開発まで2か月、建築家、計画コンサルタント、構造エンジニア、風力エンジニア、サービスエンジニア、数量およびコストコンサルタント、測量士のチームによる詳細および建設ドキュメントまで、さらに6か月かかります。アクセシビリティエンジニアとリストは続く...
仮想対物理の議論はあまり正確ではありません。また、主に仮想ツールを使用して作業を行っています。さらに、最終製品から時間的および規模的に離れています。ほとんどの場合、モックアップスケールで建物の側面をテストすることもできません。シミュレーションを使用して、何が発生するかを予測します。
複雑さに関しては違いがありますが、全体的にはほぼ同じです。私たちは相互に関連するユニットと階層化された抽象化とインターフェースの複数のレベルを持っているだけでなく、人々はコミュニケーションを非常に困難にするプロセスの小さな部分に非常に特化しています。
設計と開発の議論については、どちらのプロセスも設計に基づいていると思います。これらを分離しておくことは学問的にはいいように思えますが、物事がどのように機能するかを知らなければ設計することはできません。失敗のリスクが高まるだけです。
全体的に、OPの質問による私の（潜在的に間違っている）見積もりは、プログラミングはエンジニアリングというより芸術であるということです。なぜ人々は喜びを感じ、無料でそれをし、その中に表現と優雅さを見つけるのでしょうか？コンピュータサイエンスも（ブリキのように）工学というより科学です。既存のパーツを一緒にパッチするだけでなく、アルゴリズムを証明して、うまく機能するようにするのはなぜですか？これが意味を成しているかどうかはわかりません。私はソフトウェアの男ではありません。
ソフトウェアの設計と開発で私を襲う1つの側面は、媒体自体についてです。コンピュータは人間中心の仕事を非常に不自然にします。すべてが非常に明確であり、許容誤差はほとんどありません。これを回避するのに精神的に取り組むのは難しく、中には複雑さを捨てることでそれを回避する人もいます。他に何もない場合、これはそれと関係があるかもしれませんか？
では、それらの設計にはどのくらい時間がかかりましたか？年？二？ 10年？デザインは何かを構築する上で最も複雑な部分であり、構築自体は簡単です。
この記事 に基づくと、ソフトウェア開発は主に設計ドキュメントがソースコード自体である設計プロセスであることが徐々に理解されています。また、設計プロセスは生産プロセスとはまったく異なります。小さな要件の変更でもプロジェクト全体のアーキテクチャに大きな変化が生じる可能性があるため、経験豊富なスタッフが必要であり、計画を立てることは不可能です。この理解が アジャイル手法 の基礎であり、風洞で飛行機のモデルをテストするのと同じように、最終的な設計ドキュメントとしてコード品質を改善し、設計プロセスの一部としてテストとデバッグを行うことに焦点を当てています。
構築自体はコンパイラによって自動的に処理されます。そのおかげで、製品全体をほんの数分で構築できます。
ソフトウェアプロジェクトが大幅な遅延と膨大なコストで終了する理由は、マネージャーがまだそのような設計プロセスを推定、予測、計画できると考えているためです。これは、実際に有効であるよりも頻繁に裏目に出ます。彼らは依然として、人々を厳格な建設プロセスに結びつけることにより、最終結果がコストの増加と納期の遅れとは正反対であるにもかかわらず、彼らはどういうわけか品質を向上させることができると考えています。
エアバスA380の設計の最中に、誰かが会議に参加して、「ああ、それを三葉機として構築できるのか？」と想像してみてください。他の人たちは、「うん、うん。三葉機。翼が多いほうがいい」と言って参加した。次の3年間は、A380の設計を三葉機に変えることに費やされます。別の会議で、誰かが「三葉機？それは古い。複葉機が欲しい。片方の翼を外すだけだ」と言った。
または、橋の建設プロジェクトの途中で誰かが言うと、「ああ、私たちは海運会社と契約したところです。船は背が高いため、橋をさらに40フィート高くする必要があります。修正してください。ありがとう」
これらは、大小を問わずソフトウェアプロジェクトが驚くべき速さで失敗する理由の一部にすぎません。
ITで働いている機械工学のバックグラウンドを持つ誰かとして、私はしばしばITの低い成功率の理由について疑問に思っていました。
このスレッドの他の人と同様に、失敗の原因はITの未成熟、詳細な標準の欠如（そうですね、私は真剣です、単純なボルトの標準シートを確認したことがありますか？）コンポーネントとモジュール。
建造物建設や造船業などの他の業界にも、はるかに「強み」があります。特定のソリューションプロトタイプの知識と経験は、カスタマイズされた形式で何度も再利用されます。異なるサイズと目的の建物、船、飛行機がどういうわけかそれほど似ているのか疑問に思ったことはありませんか？ （もちろん、ルールには例外があります...）
それは、これらのプロトタイプがよく研究され、よく理解され、一般的に使用されており、実績があるためです。それは他の方法で行うことができなかったからではありません。 ITの標準化はめったに当てはまりません：（大規模な）プロジェクトはコンポーネントを再発明し、同時に研究と配信を行う傾向がありますand同じ人と！
これらは必然的に1回限りの製品につながります。これは開発と保守に費用がかかり、エラーが発生しやすく、不確実な条件下で予測できない方法で失敗します。そしてもちろん、これらの製品は時代遅れであり、書き留められ、同等の大きなコストでわずかに優れた製品に置き換えられています。 ITに必要なのは、中年の職人を効率的な工場に変えた産業革命に相当するものです。
ただし、ITを真にユニークにする要素はいくつかあります。これらの他の言及された産業とは対照的に、ITは本当にユビキタスです。それは、私たちの現代生活のeveryの側面で使用されています。したがって、ITはこれほどの進歩を遂げ、それがもたらす結果を提供できる小さな奇跡です。
申し訳ありませんが、申し訳ありません。
エアバスとボーイングは、飛行機を製造する会社の2つの例です。飛行機を製造する会社はいくつありますか？ソフトウェアを構築している会社の数と比較すると、ごくわずかです。
飛行機のプロジェクトをねじ込むのも、ソフトウェアプロジェクトをねじ込むのと同じくらい簡単です。航空機製造業界では、ソフトウェア業界と同様に参入障壁が非常に低かった場合、航空機プロジェクトの失敗が数多く見られます。
車を見てください。非常に耐久性があり高度な自動車を製造する高品質の製造業者（Land Rover、メルセデスなど）や、修理しなければ1年も続かない自動車（KiaやCherryなど）を製造する製造業者があります。これは、参入障壁が少し低い業界の完璧な例です。
ソフトウェアも同じです。バグの多い製品がたくさんありますが、Windows、Office、Linux、Chrome、またはGoogle検索は、時間通りに配信され、航空機と同様の品質レベルの非常に高品質なプロジェクトです。
多くの人が見落としているもう1つの点は、自動車、タンカー、航空機のメンテナンスにどれだけのメンテナンスが必要かということです。すべての飛行機は離陸する前に技術検査を受けなければなりません。数kマイルごとに車をチェックして、オイル交換、タイヤ交換などの定期的な作業を行う必要があります。
ソフトウェアにもそれが必要です。診断、防止、または監査ソフトウェアの状態と品質に機械/物理製品の場合と同じくらいの時間を費やした人だけがいる場合、このような記述ははるかに少ないと予想します。起動する前に毎回アプリケーションのログを読みますか？まあ..それが航空機だった場合、あなたはしなければならないでしょう;-)
デジタルビルディングブロックは1または0です。間にはありません。
機械設計にはある程度の許容範囲があります。完全ではないリベットを1つブリッジに挿入できますが、ほとんどの場合、コード内では落下しません。1であるはずの0を1回だけインスタンス化しても、プログラム全体が失敗する可能性があります。
コンピューティングの論理的でインタラクティブな性質により、非常に小さな変更であっても、大幅な失敗につながる可能性があります。
私はしばしば同じことを疑問に思いました。それは確かに感じている（時々）私たちが何をしているか何も知らないアマチュアの束のようです。私はマネージャーやその他の外部要因に責任を負わせる説明が嫌いです-私たちは開発者が私たちが作成したものに責任を負うべきです。
エラーが安いビジネスにいると思います。超高層ビルを再構築したり、販売したすべての携帯電話を呼び戻したりするのに比べて、パッチソフトウェアは安価です。
これにより、バグが日常生活の一部である文化が生まれました。彼らは肩をすくめて受け入れられます。いくつかのバグはおそらく避けられないかもしれませんが、それらは 日常業務を支配する でしょうか？とにかくバグを期待しているからといって、QAに問題があると感じていないマネージャーは完全に理解しています。バグの修正は地獄のように退屈なため、エラーのないコードを生成するために全力を尽くさないプログラマーについては理解できません。
本質的には文化の問題だと私は信じています。
エンジニアリングの標準と実践は、IT（独立した業界として）と 航空宇宙 とで大きく異なります。これはおそらく、ITが航空宇宙で標準ドキュメントに遭遇したときにITプロフェッショナルがどのように反応するかを考えると、最も簡単に理解できます。たとえば、最近インターネットで使用されている Joint Strike Fighter C++ Standards です。
多くの人が面白かったり物憂げな辞任を表明したりします（そのようにしたいのですが）。そして、多くの人は、このように消費者向け製品を届ける実際的な方法はないと主張して、あざ笑いで応えます。これは、消費者ではなく管理者の期待を踏まえると、正しい場合もあります。何もデモを行わず、数週間だけコーディングしてコーディングするプログラマーには、かなりの不信があります。神は、2週間だけ設計するコーダーを助けます。飛行機ではそうではありません。
ソフトウェアでは、人々は本当に今何かがあることを期待しています。確かに、その推論は行きます。本当にしっかりしているのに少し時間がかかります。しかし、1週間で簡単な用語で記述されたいくつかの複雑なことはできませんか？また、正直で複雑な用語で記述された複雑なことは、想像力を刺激することはめったにないことも学びます。したがって、多くのエンジニアは、想像力に富んだ非常に単純なものが創造的な方法で組み立てられる想像力豊かな世界に加担することになります（困難なことを非常にうまく行う世界とは対照的に）。
私からのいくつか：
1-標準と部品：それらは平面ですメーカー、開発者ではありません。完全には定かではありませんが、多くの部品が外部委託されていると思います。彼らは独自の電子機器を構築していません。彼らはいくつかの会社から座席を取得しています。エンジンはおそらく他の場所で開発されています。
一方、ソフトウェアプロジェクトは、ほとんどの場合、ほんの一部の小さなフレームワーク/ヘルパーを配置してゼロから開始します。
2-市場参入までの時間：飛行機にとって時間は重要な問題ではありません。エアバスのデザインは完成する何年も前に完成したに違いないと思います。 （たとえば、自動車メーカーも同じです。彼らが現在開発している最先端のテクノロジーは、5〜10年後に登場します。）
ソフトウェアについては、非常に機敏である必要があります。もし私が巨大なプロジェクトを始めて、何も変更せずにそれを開発するのに3年かかるなら、私がもう利用できないテクノロジーに依存している可能性、または私の製品が完全に古くなっている可能性はかなり高いです。これにより、多くの問題が発生します。
3-リリースサイクルとバージョン。 -「リリース」された飛行機は完全に完成する必要があります。安定したベータ版、ナイトリービルドなどはありません。さらに、それが完了すると、小さな方法でのみ変更できます。既存のボーイングに100席のレベルを追加することはできません。それは不可能です。
一方、ソフトウェアには、多くの場合「機能するビルド」である増分変更がありますが、必ずしも完成した製品ではありません。また、ITでは、「50トンの荷物を収納できる別の荷物室を飛行機に追加しましょう」と言うことも珍しくありません。
答えは非常に簡単だと思います：
1）物理的な構造と実装は、人々がそうである限り存在し続けています-物理的なプロジェクトを実装するための方法と技術を開発するために何千年もかけてきました。まったく新しい、異なるスキルセットを必要とするソフトウェアの「構築」は、50年以上前のものではありません。まだすべてを把握するのに十分な時間がありませんでした。
2）バーチャルな構築はより困難です。物理的な現実がまったくないものを頭の中で「見る」必要があります。それはあなたがあなたの製品がどのように見えることになっているのか、そしてそれを作成するためにとるべきステップを知る前に多くの情報を分析し抽象化することを要求します。橋や建物を建てるときはそうではありません。
3）ソフトウェアの障害やバグの原因を見つけることは、物理的なエンジニアリングを行う場合よりもはるかに難しいことがよくあります。桁が曲がる場合、それが曲がっている場所がわかり、サポートがそれを保持して失敗しているなどがわかります。ソフトウェアの欠陥を見つけるには、大量のコードと相互作用するプロセスを調査する必要があります。困難で時間がかかり、物理構造がそうであるように、物理学と数学の法則。
Jack Ganssleの組み込みミューズからの記事の逐語的コピーを使用して回答してみます。これはどこでもファームウェアを言いますが、精神的にそれをソフトウェアで置き換えてください。
何と比較しますか？
ファームウェアは、宇宙で最も高価なものです。元ロッキードマーティンCEOであるノーマンオーガスティンは、彼の素晴らしい本「オーガスティンの法則」で、国防コミュニティーが遭遇した問題について明らかにする物語を語っています。高性能戦闘機は、燃料範囲と性能という相反するニーズの微妙なバランスです。スピード対重量。 70年代後半までに、戦闘機はかつてないほどの重さになったようです。常により大きな利益を追求している請負業者は、彼らが多くのコストを加えることができる何かを無駄に探しましたが、それは何の重さもありませんでした。
答えはファームウェアです。無限のコスト、ゼロの質量。現在、アビオニクスは戦闘機のコストの半分以上を占めています。最新のアメリカの戦闘機、F-22を考えると、これはかなりの変化です。オーガスティンは、この話を語るとき、実質的に歓喜の声を上げます。
しかし、なぜソフトウェアがそれほど高価なのでしょうか。 Tom DeMarcoがかつてこの3つの単語でこの質問に回答しました。彼は比較的退屈なビジネスケースについて議論を続けましたが、その答えは何年にもわたって私の心に響きました。何と比べて？ソフトウェアを使用して、前例のない複雑さの製品動作を日常的に作成しています。もちろん、コードは高価です。しかし、文明の歴史のなかで、それほど複雑なものを構築した人はいません。
Wikipediaから恥知らずに持ち上げられた、次のバブルソートを検討してください。
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]); }それは、たった1、2時間で放棄された、たった110の非スペース文字です。ソフトウェアがなく、他の戦略を使用してソートを実装しなければならなかったとします。費用はいくらですか？
機械技師は、彼の職業がコンピューターよりもずっと前にソーターを構築したことを自慢するかもしれません。 IBMの1949年代のモデル82カードソーター（ http://www.columbia.edu/acis/history/sorter.html ）で、コードスニペットよりも毎分650カードのスループットが高いことを考慮してください。 4 MHz Z80でも管理できます。もちろん、モデル82は一度にカードの1列のみをソートしました。デッキを完全に分類するには、何十回ものパスが必要になる場合があります。
この獣を設計して構築するのにどれくらいの時間がかかりましたか？年、間違いなく。また、その機能は、非常に高速で巨大なデータセットを処理できるコードに比べると見劣りします。しかし、それは1949年でした。FPGAとVHDL、またはCPUなしで、電子コンポーネントからバブルソートを構築するのにどのくらい時間がかかりますか？
1時間で、チップレベルの上の大まかなブロック図を管理しました（ブロックには、「加算器」、「16ビットラッチ」などの名前が付いています）。しかし、シーケンスロジックは明らかにかなり厄介であるため、適切な方程式を書くのはそれほど難しくないとある時点で想定して、PLDを投げました。そして、そう、それはおそらくプログラム不可能なロジックのルールに違反しますが、妥当な時間内にゲートを使用してそのすべてのロジックを設計およびデバッグすることは、バックガロンガスと同じくらいありそうにありません。
16ビットのワードとアドレスを想定すると、回路には約12個の16ビットラッチ、加算器などが必要になります。プラスメモリ。そして、私は未分類のデータがどのようにRAMに到着するのか、または結果がどのようにエクスポートされるのかを知りません。これらは不特定の設計要件です。ソフトウェアのみのソリューションは、書くという行為によってこれらの要件を自然に解決します関数プロトタイプ。
大まかなブロック図を回路図に変換するには、1日かかる場合があります。次に、PCBを設計および製造し、部品を注文してロードし（そして、予期しないが避けられない寿命末期の問題に対処するために設計を変更する）、そしてもちろん回路を機能させる時間があります。ボード、部品、適切なテスト機器に何週間もの労力と多額のお金を費やすことになるかもしれません。
これはすべて、7行のコードを置き換えるものです。 10,000未満の実際の組み込みプログラムはほとんどありません。多くは100万を超えます。実際の超大型コンピュータプログラムを置き換えるには、どのくらいのハードウェアとエンジニアリングが必要ですか。
スプレッドシートのような実際のプログラムを考えてみましょう。プロセッサなしで回路を作るのにどれだけの回路が必要でしょうか？それは都市の大きさかもしれません。
ファームウェアは宇宙で最も高価なものですが、それは解決する問題の想像を絶するほどの複雑さのためです。しかし、他のどの方法よりもはるかに安価です。そのため、上司が苛立たせてなぜソフトウェアにこんなに時間がかかるのかと尋ねるとき、あなたは何を言うべきか知っています。 何に比べて？
だからそこに！ソフトウェア/ファームウェアは比類のない複雑さを持っています。
大規模なプロジェクトは、多くの場合、大規模な組織で発生します。大規模な組織で働いたことがない場合は、パフォーマンスと生産性を落とすことが保証されている1つがあります。それは官僚です。
驚くべきことに、多くの人々は官僚制が何であるか（それはしばしば政治と混同されます）、あるいは官僚制問題を抱えているかどうかさえ知らない。
最近、スマートカード認証を実装するプロジェクトを締結しました。当初は3か月と推定されていました。 15ヶ月かかりました。遅延の費用、予算、範囲、または技術的な理由はありませんでした。スコープは実際にはかなり狭いものでした-昇格された特権を持つアカウント（管理者アカウント）のみ、合計で約1,200アカウントです。
もう1つの重要な要素は、ビジネスパートナーです。これにはベンダーが含まれます。パートナーがプロジェクトで遅延を引き起こす問題を抱えている場合、遅延の問題を実際に解決するオプションはあまりありません。彼らはあなたのために直接働きません、そしてあなたは原因であるかもしれないパートナーでその一人を解雇することができないかもしれません。パートナーは解雇されるか、金銭的ペナルティまたは阻害要因の対象となる可能性がありますが、それによってプロジェクトで遅延が発生したという事実は変わりません。これは、ボーイングが Boeing 787 Dreamliner を使用してマンモスソーシング戦略を実行したときに発生したことです。
私はあなたのために短いバージョンを持っています：
何をするのも簡単で合理化されるものは何でも、私たちの代わりにそれを行うためのプログラムを書きます。
そして、代わりにメタプロセスと戦います。
それ自体はそれほど真実ではありませんが、毎日、ブログエンジンを作成する代わりに、何千ものブログがセットアップされています。特別に設計されたデータベースアプリケーションを作成する代わりに、毎日、何千ものExcelマクロが作成されます。
他にもたくさんの要素があります-そのうちのいくつかはここで言及されています-しかし、私はこの点を議論に加えたかったのです。
ソフトウェアのエンジニアリングと管理は、他の多くのエンジニアリング領域とは根本的に異なります。成果物は物理的なものではなく、生産プロセスは設計および開発プロセスです。ソフトウェアのコピーをもう1つ作成すると、限界コストは本質的にゼロになります。すべてのコストは最初のコピーの開発にあります。
分野としてのソフトウェアエンジニアリングと管理は比較的若かったため、ソフトウェアの開発とエンジニアリング全体を妨げる、事実と見なされる誤った情報と誤りがあります（ このリファレンスを参照 ）。
すべての開発者が平等に作成されているわけではありません。良いものもあれば、そうでないものもあります。
いつも他の人のコードを読んでみて、私の言っていることを感じてください。追加の論理ステートメントが多すぎると、リスクが増える可能性があります。これらのリスクは、不正な動作やバグにつながる可能性があります。十分な論理ステートメントがなく、今ではnull参照があります。優れたプログラマはこれを理解し、いつ、どこで、何をするべきかを知っています。しかし、誰も完璧ではありません。物事は複雑です。他人のよく考えられていない作業を追加すると、プロジェクトがどのように実行されるかを簡単に確認できます。
説明責任の欠如...航空機が墜落すると人々は訴えられる。ソフトウェア業界は、ソフトウェアの欠陥について責任を負わないため、堅牢で安全な製品を作成するインセンティブがありません。
大聖堂の建設には最大100年かかりました。
一部のエアバス機では、100万行のコードが必要です。
何かを改善している時間が長ければ長いほど、得られる改善も大きくなります。ソフトウェア業界に数百年の試行錯誤を重ねて改善することで、バグのないしっかりとした巨大なプロジェクトを開発するのにどれだけかかるかがわかります。または欠陥。
ほとんどの大規模プロジェクトでは、サブプロジェクトの分離度が高く、少数の設計制約を定義できます。これらのサブプロジェクトがそれぞれ完了すると、プロジェクト全体が機能します。サブプロジェクトで問題が発生しても、全体の作業は問題になりません。サブプロジェクトを完了するための代替方法を探すだけです（たとえば、別のエンジンを使用します）。
これは可能ですが、ソフトウェアプロジェクトでは、現実的にも人間の問題としても、困難です。
一部では、他の業界がこの種の分離可能性が良いことであるという難しい方法を学んでいます。たとえば、ロールスロイスの航空機エンジンを使用する場合、特定のデザインの翼でのみ機能する特別なロールスロイスボルトとアタッチメントポイントを使用する必要はなく、プラットとホイットニーに切り替えようとすると、翼全体を一から設計し直す必要があります（そのため、機体を完全に再設計する必要があります。そのため、別の座席を購入する必要があり、別の機内エンターテイメントシステムを購入する必要があります。これ...）いくつかのリンケージがあるかもしれません-注意せずに単にエンジンを交換することはできません-しかし、そのようなものが最小化されている場合、大きなプロジェクトは一般的にうまく機能します。
相互にクリーンなインターフェースを持つ小さなソフトウェアプロジェクトのクラスターとして設計された大きなソフトウェアプロジェクトは、大きなプロジェクトである限り、特に頻繁に失敗するとは限らないと仮定します小さなプロジェクトのクラスターによって実際に解決されます。 （この点で間違いをする可能性があります。）
ソフトウェアシステムの構築は、物理構造の構築とは大きく異なります。つまり、の実装は大きく異なります。たとえば巨大なタンカーを建造するときは、ロボットや手作業で部品を溶接したり、すべてのナットとボルトを締めたり、塗装したり、装飾品をすべて持ち込んだりするなど、比較的単純な（ただし簡単ではない！）タスクをたくさん行います。設備や家具など。これはすべて、本当にシンプルなことです。
ただし、ソフトウェアに関しては、もっと複雑になります。たとえば、製品の安全なログインとユーザー資格情報を保存する部分をどのように正確に実装しますか？どのライブラリとツールを使用できますか？どのライブラリとツールに精通していますか？ハッシュ+ソルト関数をどのように正確に記述し、それが安全であることをどのように保証しますか？これを非常に多くの方法で行うことができるため、実際の実用的な設定は不可能です- デザインパターンこれらの種類のもの。はい、上記の設計パターンdoは「ベストプラクティス」として小規模に存在しますが、すべてのソフトウェアシステムは他のものとは非常に異なり、フィールドは非常に速いペースで進歩および変化するため、本質的に追いつくのは不可能です。
家を建てるとき、メインの支持壁が不十分であり、交換する必要があるように見えるという問題に実際に遭遇することはありません。これまでの進捗状況を解体し、支持壁をやり直すことによってベースから始める必要があります。 。 設計フェーズでこのような問題に取り組みます。建物に必要な支持壁の種類を予測することは比較的簡単だからです。
しかし、ソフトウェアはそうではありません。製品全体を1つのエンティティとして実際に設計して実装することはできません。通常、ソフトウェア設計プロセスは反復的であり、製品の実装とテストが行われるにつれて、目標と要件は変化します。ソフトウェア開発は全体として反復プロセスであり、通常は予期しないときに変更が行われ、そのような変更は多くの場合、より多くの作業、複雑さ、そして残念ながら最終的にはより多くのお金を必要とする課題を課します、時間と労力を正しく得るために。
したがって、本質的に、大きなプロジェクトを提供し、プロジェクトのタイムラインとロードマップを見積もることが難しい理由は、ソフトウェア開発、特に実用的な設計が非常にcomplexフィールドであることです。 複雑さが根本的な問題です。
Airbus A38 は、ご指摘のとおり、成功したプロジェクトではありませんでした。たまたまCAD/CAM会社で働いていましたが、会社によって異なるバージョンのソフトウェアを使用していたため、Airbusのプロジェクトも数年遅れていると言われました。つまり、世界のさまざまな場所でさまざまなパーツが設計されていました。また、統合する際に、すべての設計を統合できないことがわかったため、1つのバージョンで再設計する必要があります。だからそれを見て成功したとは思いません。それが2〜3年前に来ていたならば、それはエアバスのゲームチェンジャーであったでしょう。
また、堅牢なソフトウェアについては、飛行機、車（ABS、EPS、気候制御など）またはスペースシャトルを見て、50％以上のソフトウェアが実行されており、非常に堅牢であると信じています。それは、私たちがソフトウェアにもっと近づいているだけであり、ソフトウェアプログラムがもっとたくさんあるので、それらにより多くのエラーが見られます。
訪問： http://www.globalprojectstrategy.com/lessons/case.php?id=2 とエアバスA380がどれだけ成功したかを確認してください。
エンジニアリングのバックグラウンドを持つここのソフトウェアエンジニア、および建設で働く妻。私たちは仕事の違いについて長い議論（と議論）をしてきました。
ソフトウェアエンジニアリングは、新しいものを設計することです。基本的なほとんどすべてがどこかでオープンソースライブラリで行われています。ソフトウェアエンジニアを雇うほとんどすべての仕事で、彼女は存在しないものをデザインする必要があります。
建設やエンジニアリングのほとんどの形式のようなものでは、そうでなければソフトウェアの「ライブラリ」にあるものはすでに完全に設計されています。塔を建ててみませんか？いくつかの変更を加えて、既存の構造から計画をコピーして貼り付けるだけです。
事実、私がエンジニアにならないことに決めた主な理由の1つは、既存の発明に対して10％の改善を設計するのにほとんどの時間を費やしていることです。そのとき、同じ時間を使用して、ソーシャルネットワークのようなより目に見える何かをプログラムすることができます。 。
エンジニアリングには多くの新しいデザインはありません。非常に熟練したエンジニアとは、既存のデザインを操作して新しいものにしたり、改善したりできる人です。しかし、ほとんどすべてのプログラマは、デザインを変更したり、ハックしたり、何か新しいものを作成したりすることが期待されています。
Assembly からC、C++、Java、JavaScript、C＃、PHPなど、標準がどこまで完全に変更されたかを振り返ります。 10年前や20年前から再利用できるコードはそれほど多くありません。これは言うこととは非常に異なります...数十年前から設計を改善し続けることができる自動車または航空産業。
プロジェクト管理はソフトウェアで難しいことで有名です。時間の見積もりは仕事をしている人が行うのが最善ですが、見積もりを立てるのに忙しいときは、コードを記述していません 。これは、プロジェクト管理をまったく回避するように人々を誘惑します。
多くの場合、多くのコードは特定の人に依存しており、これらの人が遅れたり実行できない場合、コードは先に進みません。対照的に、自動車を作りたい場合は、タイヤ、シャーシ、バッテリー、エンジンなどを組み立てるために、さまざまな人を雇うだけです。オブジェクト指向の既存のフレームワークはこれを可能にしますが、すべてを最初から設計する場合は実用的でない場合があります。
ソフトウェアでエラーが発生する可能性があります。テストはコストがかかる可能性があります。ソフトウェアでは、クラッシュを修正できるだけで、すべてのテストをスキップするのは非常に魅力的です。ほとんどのエンジニアリング形態では、「クラッシュ」は致命的となる可能性があります。
extreme programming （実際にソフトウェアメガプロジェクトで使用された）のような広範なテストを使用するプログラミング方法があります。しかし、締め切りが厳しくなっているため（意図的に厳しくすることができます）、プログラミングをすべてスキップしてバグを起動するのは魅力的です。 「常にすべてのバグを修正する」という Joel Spolsky スタイルは、長期的にはより多くの時間を節約しますが、無規律はこれをスキップして失敗します。
小さなプロジェクトの方がいいです。妻はかつて私に大企業に就職するように頼みました。大企業は悪い企業であるという議論に終わった...彼女にとって、大企業には多くのリソース、経験、機能的なプロジェクト管理、適切な手順がありました。私にとって、大企業は恐竜であり、ほとんどの時間はコードの修正、テスト、およびドキュメント化に費やされています。
100万ドル規模のITプロジェクトが10人未満で行われているのを見てきました。より多くの人々がプロジェクトを減速させ、不必要な官僚主義を加えたでしょう。 WhatsApp は、数十億ドル相当の「小さな」プロジェクトの例です。大きなプロジェクトが不可能ではないというわけではありませんが、ソフトウェアで数十億ドル相当の価値を生み出すために何千人もの人々を必要としないだけです。
「大規模プロジェクト」の定義は歪んでいます。
大規模なプロジェクトは、技術的には時間通りに、そして完璧に、何年にもわたって何度も構築されてきたものであることを認めれば、提供することができます。
- パックマンクローン。
- 電卓
- テキストエディター
私はあなたが考えていると確信しています... "しかし、それらはsmallプロジェクトです！テキストエディタはsimpleです。"私はあなたに同意しません。コンピュータは法外に複雑です。オペレーティングシステムにユーザーをインストールしてセットアップするだけでは困難な場合があり、OSを作成したり、ハードウェアを構築したりすることさえしませんでした。
あなたが話しているプロジェクトは、宇宙探査に似た巨大なプロジェクトです。銀河間旅行を開発するのにかかる時間をどのようにして知っていますか？どのモデルに基づいていますか？あなたは、既知の既知、既知の未知、未知の既知、そして最後に、未知の未知を持っています。これらは、たまたまソフトウェア開発でよく出てきます。
問題は期待の一つだと思います。テクノロジーが存在するからといって、それを使用することがしばらくの間成功する（または使用するのが賢明である）ことを意味するわけではありません。他の産業がソフトウェア産業のように振る舞った場合、10年の終わりまでにブラックホール式の掃除機が販売されるでしょう。あるいは、一部の「ビジョナリー」は、月の基地を構築するためのリソースを持っていて、スターバックスが訪問者の体験を本当に「丸める」と決定するでしょう。問題はソフトウェア産業ではないと思いますが、期待がに置かれました。
couldが言及されるのはそれだけではありませんが、1つの基本的なことを指摘する価値があると思います。ほとんどの製品は、既存の動作に適合することを目的としています。画期的な画期的な製品（たとえば、車）でさえ、通常、既存の動作に適合するように構築されており、単純にする/簡単にする/安くする/それを行うために何でもするだけです。はい、しばしばsome既存の動作にも副作用があります（たとえば、馬の食べ物ではなく車の燃料を手に入れるなど）が、後者のほとんどはかなりマイナーな副作用です。
対照的に、ユーザーの動作を変更しないほとんどすべてのソフトウェア（たとえば、ユーザーがかなり簡単に仕事を行えるようにする）は、基本的に1日目から完全に失敗することが保証されています。さらに悪いことに、大規模なソフトウェアプロジェクトは、個人レベルでのユーザーの行動が関係しますが、大規模なグループの行動は、多くの場合組織全体です。
つまり、ソフトウェア自体の設計は、多くの場合、最も簡単な作業です。難しいのは、人々のために人々の仕事を再設計することです。それを始めるのは難しいです。うまくいくだけでなく、受け入れられる方法でそれを行うことは、いっそう困難です。
他の質問で実際に取り上げられていない理由の1つは、ソフトウェアの分野が、マテリアルベースの世界ではまれにしか発生しない速度で革新することです。
この理由の1つは、ソフトウェアの構築にソフトウェア（プログラミング言語、ビルドツール、IDE）が使用されるため、ソフトウェアの進化が前向きなフィードバックサイクルであることです。これはレイカーツワイルの 加速返品の法則、 の最も明白な例であり、指数関数的に増加する速度で進行します。 1つのフレームワーク、プログラミング言語、通信プロトコルを習得したら、次は 次に進む時間 です。
飛行機がソフトウェアのように構築されている場合、他のすべてのモデルで材料を変更し、18か月ごとに容量と速度を2倍にし、新しいモデルごとにエンジン技術を発明したものに置き換え、水泳と地球外生物の検索機能を追加します生活。
ああ、そして理想的には、音声コマンドを聞いて、完全に没入型の映画館、ペイントボールアリーナ、仕事が終わったら暗い部屋のあるナイトクラブを兼ねています。 同じことです！（AからBに確実に到着した飛行機を製造した会社は、映画館、ペイントボール、ナイトクラブの機能を備えた会社が登場してから1年で腹を立てましたアウト。）