プログラミングの難しさに関するブルックス
この記事のタイトルは「銀の弾丸はありません-ソフトウェアエンジニアリングの本質と事故」です。 プログラミングの本質は、まず、特定のプログラミング言語でマシンに命令を書くことではなく、問題領域のエンティティを表す相互作用するエンティティの詳細な構造を開発することと、この構造の内部整合性をチェックすることである（そしてこれに反対することは難しい） したがって、たとえば、問題領域のレベルの概念で動作するコンピューター言語、またはソフトウェア開発を大幅に促進するように設計された他のツールを発明したとしても、例外を確立するには、実世界のオブジェクト間の関係を正確に判断する必要があるため、プログラミングは依然として困難なタスクのままです状態間の可能なすべての遷移などを提供します。 したがって、開発の複雑さを大幅に（1桁または2桁）削減できるソフトウェア開発ツールはありません。 Brooksがプログラミングの主な複雑さを理解しているのは、問題領域の相互作用するエンティティの構造の説明です。
実用確認
S. McConnellの著書、Professional Software Developmentでこの記事のレビューを読んだとき、20年以上前に出版された彼の談話にBrooksがどれだけ先見の明があるかについて驚きました。 この例としては、私たちの時代では、視覚的なプログラミング言語（LabVIEW、SFC、LDなど）があり、対象領域のレベルでのみ動作します。 私はすぐに私の練習でさらに2つの例を見つけました。
私が勤務するオフィスは、エネルギー施設（州の地区の発電所、水力発電所、原子力発電所、火力発電所など）向けのSCADAシステムの開発に携わっています。 システム全体を開発するプログラミング部門と、特定のオブジェクトのグラフィックディスパッチャワークステーションの開発を行う設計部門の2つの部門に分かれています。 2番目の部門は、基本的に問題領域のレベルでプログラミングを実行し、グラフィックブロックを使用してデータベースにリンクし、特別な高レベル言語を使用して追加機能を記述します。 また、この部門の複雑さと作業量は、プログラミング部門と同じです。
仕事と並行して、私は大学院で勉強し、生物の遺伝的発達をモデル化するための媒体を開発しています。 これで、かなり単純な数学的ルールのセットを使用して、研究者が生物の生命過程を説明できる、かなり普遍的なモデリングシステムを開発しました。 そして、ここでは、エンドユーザーである生物学者にとって、実験データに基づいたこの記述の作成が主要な問題であるという事実に直面しています。 これは、まさに「問題領域の相互作用するエンティティの詳細な構造を開発する」必要性によるものです。 さらに、この問題は、最初は私たちに思われたように、より便利なユーザーインターフェイスを作成しても解決できないようです。 今、私たちはそれに取り組んでいます...
結論
このすべてからどのような結論を引き出すことができますか？ まあ、まず、私たち（プログラマー）は、今後50年間で仕事がなければ、間違いなくそうはならないでしょう。 第二に、仲間の開発者に警告したいと思います：ユーザーの作業を自動化するように設計されたツール環境を開発している場合、記述された問題に遭遇するかどうかを考えてください-エンドユーザーは（何らかの形で）プログラミングスキルを必要とします。
UPD：ブログ「開発」に移動
UPD2：Comrade Fortumsのおかげで、視覚プログラミング言語の不正確さが修正されました