失敗したソフトウェア開発のアイデアやテクニックの良い例は何ですか？

具体的には、大衆のアイデアが間違っている場所の例は何ですか。なぜ人々はなぜそもそもアイデアにとらわれたのですか？そして、なぜアイデアは却下されたのですか？あるいは、アイデアはまだ健在で、もしそうならなぜですか？

たとえば、CORBA（および他の同様のテクノロジ）を、ソフトウェアのコンポーネント間の通信の問題を解決しようとしたものと説明する場合があります。多くの人が、さまざまなコンポーネント間の契約を定義する必要があると感じました。最終的に、HTTP + JSONは大衆の問題を解決し、ThriftやProto-bufなどのさまざまなRPCメカニズムがポップアップしました。

基本的に、コンピューターの外の世界と同じように、アイデアやテクノロジーは、注目を集めたり、活用したりするために競います。しばらくの間は勝者のように見える人もいれば、次のビッグシングの登場で曖昧になっていく人もいます。それは実際に良い方とは関係ないかもしれません。VHS vs Betamax、またはさまざまなDVDフォーマット間の最近の戦争を目撃してください。

CORBAは巨大で扱いにくく、使いづらいものでしたが、当時は一部の人々が発明できる最高のものでした（World Wide Web（およびHTTP、Java、XMLなど）が広く知られるようになる前に設計されたことに注意してください）。また、委員会によるデザインの典型的な例でもあり、すべてのアイデアを満たして皆を満足させ、最終的には無駄に肥大化しました（少なくとも今日の目では見られます）。その価格は言うまでもありません。FOSSの登場により、すぐに法外な価格になりました。

最終的に、HTTP + JSONは大衆の問題を解決しました

少なくとも、いくつかの同様の「最終的な解決策」が上昇し、最終的には下降しないのを見ている人にとっては...当時、CORBAについて同様の感情があったことを覚えておいてください;-)

CORBAの上昇と下降から引用するのがふさわしいと思います。

CORBAの歴史はコンピューティング業界で何度も見られてきたものであり、現在のミドルウェアの取り組み、特にWebサービスが同様の歴史を再現する可能性は高いと思われます。[...]

全体として、OMGのテクノロジー採用プロセスは、CORBAが衰退する主な理由と見なす必要があります。このプロセスは、委員会による設計と政治的操縦を奨励し、技術的卓越性は言うまでもなく、技術的平凡を達成するのが困難になるところまで行きます。さらに、バラバラな機能を追加すると、建築のビジョンが徐々に侵食されます。[...]

OMGのような民主的なプロセスは、優れたソフトウェアを作成する上で非常に不適切です。しかしながら、既知の手続き上の問題にもかかわらず、業界はテクノロジーを生み出すために大規模なコンソーシアムに依存することを好みます。現在のミドルウェアの特効薬であるWebサービスは、OMGと非常によく似たプロセスを使用しており、多くのアカウントで、内紛、断片化、アーキテクチャーの一貫性の欠如、委員会による設計、機能の肥大化に悩まされています。WebサービスがCORBAと非常によく似た歴史を制定することは避けられないようです。

ここで別の角度から：「大衆のアイデア」という用語を読んだとき、CORBAや他の標準とは非常に異なるものについて考えました。これらは通常、1人または小さなグループのアイデアです。「カウボーイコーディング」、「コードと祈り」、「自分のマシンで機能する」など、悪名高い習慣/見方について考えました。これらは、ほとんどすべての初心者の方法であるため、私見の本当の「大衆のアイデア」です。開発者は直感的にコードを書き始めます。そして、それらは空間でも時間でもスケーリングされないため、間違っています。この方法では、保守可能で拡張可能な大規模なプログラムを作成することはできません。しかし、残念ながら、世界中の専門店でこの方法で仕事をすることは、例外ではなく、今でも当たり前のことだと思います。

これのもう1つの極端は、CMM、RUP、ウォーターフォールなどのビッグM方法論で表される、SW開発への「正しいアプローチ」に関する多くの管理者および理論家のアイデアです。これらすべての背後にあるアイデアは、必要なのは適切なプロセス、そして開発者が実際に誰であるかに関係なく、決定論的な方法で高品質のソフトウェアを自動的に生成し始めます。同じゲームがアジャイルメソッドを使用してプレイできることにも注意してください。これは単なるラベルの変更です。自分の開発チームに適切なメンバーを選択（および維持）することが開発プロセスよりも重要ではないと考えているマネージャーは、そのプロセスがどちらであっても失敗します。しかし、プロセスに対するこの信念は依然として蔓延しているようです-おそらくそれはまだ管理学校で教えられているのでしょうか？

よく失敗する人のよくある例は、ウォーターフォールモデルです。これは、Winston Royceの論文「Managing the Development of the Development of Large Software Systems」にも記載されているステレオタイプのウォーターフォールモデルの図です。

この画像の後には次のテキストが続きます。

私はこの概念を信じていますが、上記の実装は危険で失敗を招きます...開発サイクルの最後に発生するテストフェーズは、タイミング、ストレージ、入出力、転送などの最初のイベントです。分析されたものとは異なる経験です。これらの現象は正確には分析できません。それらは、例えば、数理物理学の標準的な偏微分方程式の解ではありません。しかし、これらの現象がさまざまな外部制約を満たせない場合、不変の大きな再設計が必要になります。孤立したコードの単純な8進パッチまたはやり直しでは、このような種類の問題は修正されません。必要な設計変更は非常に破壊的である可能性が高く、設計の基礎となり、すべての根拠を提供するソフトウェア要件に違反します。要件を変更する必要があるか、設計に大幅な変更が必要です。事実上、開発プロセスは原点に戻り、スケジュールおよび/またはコストで最大100％の超過が予想されます。

このホワイトペーパーの後半で、Royceは、現在のフェーズと前のフェーズの間の反復、および要件分析と設計の間のサイクルと、設計コードとテストの間の別のサイクルを含む代替プロセスモデルを示します。彼はまた、いくつかのドキュメントを特定し、どのフェーズで完了する必要があるかを特定し、顧客の関与と各フェーズ内の複数のウォーターフォールを提唱して、関連するすべてのアーティファクトの分析、テスト、および使用法を含めます。実際には、Royceが論じていることは、アジャイル手法への初期のアプローチと見なされる可能性があります。ただし、計画主導型ですが、アジャイル運動の基礎となっています。

なぜ人々が最初の滝に引っ掛かったのか、私にはわかりません。彼らはリスクを取って失敗を招くのが好きだと思います。

より高い抽象化レベルからのコードの自動生成、または自動プログラミング。

ウィキペディアの記事には履歴情報がいくらか不足していますが、プログラマーがコンピューターよりも高価になったときから、これはマネージャーの夢​​でした。

FortranやCobolなどの高水準言語の開発後、レポート作成などの特別なドメイン用の言語の開発が始まりました。 EasytrieveとSASはその例です。

1980年代には、CASEツールが大流行しました。CASEは、コンピュータ支援ソフトウェアエンジニアリングの略です。エンジニアリングの原則を厳密に適用することで、ソフトウェア開発がより速くなると考えられていました。これらのツールが費用に加えて追い付かなかった主な理由は、ツールが効果的に機能するために必要な高レベルのデータ標準化でした。

1990年代にインターネットが顕著になった。インターネットが促進したプログラミングの種類は爆発的に増加しました。プログラマーは、イラスト、マップ、写真、その他の画像に加えて、簡単なアニメーションを、これまでにない速度で、いくつかのよく知られた方法で処理する必要がありました。これらのオブジェクトを生成するテクノロジーの数は倍増しました。自動プログラミングの夢は薄れました。

より安価な場所へのプログラミングのアウトソーシングは、プログラマーのコストを削減するために残っている数少ない方法の1つです。アウトソーシングの問題には、通信の問題と仕様の問題があります。

形式的な方法

むかしむかし、ソフトウェアが正しいことが証明できると提案されました。（テストではエラーがないことを示すことはできませんが、証明は可能です。）残念ながら、プログラムの証明を考案することにはいくつかの大きな欠点があります。

• プログラムを書くよりも困難で時間がかかります。
• プログラム全体をカバーする必要があります。つまり、ライブラリ、OSなどの証明が必要です...
• これらのバグは偶然の原因である可能性があるため、バグがないことを証明するものではありません。

このコンセプトは70年代に非常に人気がありました。

リンケージ：http : //en.wikipedia.org/wiki/Formal_methods http://c2.com/cgi/wiki?ProofOfCorrectness http://c2.com/cgi/wiki?PractitionersRejectFormalMethods