「プログラマーは、一流の数学者が抽象化と論理的思考を持ち、エジソンの才能と組み合わせて、ゼロからゼロまで何でも構築できる能力を持たなければなりません。 彼は会計士の正確さとスカウトの洞察力、探偵小説の著者の想像力、そして経済学者の地味な実用性を組み合わせなければなりません。 エルショフ
まえがき
「プログラマーがプログラムを書くのと同じ方法で家を建てた場合、最初の空飛ぶキツツキは文明を破壊するだろう」という幅広い意見があります。 インドのプログラマーの教祖であるMurali Krishna Chemuturiの提案で、インターネットはこの引用の原作者をGerald Weinbergに帰属させていますが、Geraldの個人サイトでは検索されません。 おそらく、プログラミングの心理学について最初に話した人は、この声明とは無関係です。 そして、ここに理由があります。
この格言は、デマゴジック受信機の例です。 ここでは主な前提がありません。ソフトウェア開発は家を建てることと同じです。 この前提は、デフォルトでは、証明を必要としない信頼できる事実として暗示されています。 このトリックを使用すると、経験の浅い読者は、プログラマーはビルダーとは異なり、正しい場所から手を伸ばさないという誤った結論を下すことを余儀なくされます。
材料の生産（物理世界のオブジェクトの処理）は、数万年の歴史があります。 数学、物理学、化学、地理学、地質学、生物学など、自然科学に関する膨大な知識がこの道に沿って蓄積されました。
冷静な考えを聞かせてください。 ソフトウェア開発は新しい種類の人間の活動であり、その歴史には半世紀以上の歴史があります。 投稿では、ソフトウェア開発の基本的な機能について、それを素材の生産と区別し、それから生じる結果についてのビジョンを提示したいと思います。
機能とその結果
機能＃1。 プログラミング-知的活動
簡単に言うと、新しい建物、橋、車、ロケットのアイデアからその実装までの道筋は次のとおりです。NIR-OKR-Zavod。 このピラミッドの最上部には、アイデアを生み出し、新製品を設計する業界研究機関があります。 ピラミッドの2階では、設計者が設計局で働いており、そのタスクは、部品、材料仕様、製造およびアセンブリ技術の図面に新しいプロジェクトを実装することです。 下位レベルには生産施設があり、エンジニアや労働者がこれらの図面、仕様、技術を「鉄で」具現化する工場です。プログラマが生成するものは重要ではありません。これは、プロジェクトチームの集合的思考プロセスの結果であるブレインウェアであり、プログラミング言語の1つで実現されます。
プログラミングの第一人者であるF.ブルックスは、1975年に次のように書きました。 彼は空中と外に城を建て、想像力で創造します。 作品で使用されている他の素材を見つけることは難しく、柔軟性があり、磨きや加工が簡単で、壮大なデザインを実現するのに利用できます。
類推すると、プログラマーは記述されたピラミッドの最上部でのみ作業します。 プログラミングは設計と設計のみです。 ソフトウェアプロジェクトの設計局の役割は、コンパイラとプログラムコレクターによって果たされます。 そして、設計文書を消費者がアクセスできる製品に翻訳するプログラマーのプラント類似物は、作成されたプログラムが実行されるコンピューター複合体です。
当然の結果＃1。 同じ経験を持つプログラマーのパフォーマンスは、まだ10倍異なります。
ブルックスは、パフォーマンスの約10倍の違いについて話しました。 Robert Glassは、パフォーマンスに27倍のばらつきがあることを実証した実験に言及しました。
人がどのような場所を考え、どのようにこの場所を作ったかは、誰にもわかりません。 他の産業では、労働の科学的組織の専門家がすぐにスタハノバイトの労働者の背後に配置され、進歩的な技術プロセスのマップを作成し、新しい生産基準を確立しました。 そして、スペシャリストはプログラマーの後ろから何を見ますか？ Habrahabr.ru？
当然の結果2。 失敗したソフトウェア開発プロジェクトの統計は、近い将来に変わる可能性は低いです。
OCDに到達するまでに紙上に残っていた研究プロジェクトの数と、トピックが終了してさらにOCDが終了した数を思い出してみましょう。 業界の研究機関で実施されているプロジェクトの総数に達したイノベーションの割合は、成功したソフトウェアプロジェクトの割合に匹敵すると考えています。 そして、これは研究所の科学者が数学、物理学、化学のかなりよく研究された法則に依存しているという事実にもかかわらず、そして同様の法則のプログラミングにおいてはまだ発見されていません。 これがプログラミングの2番目の機能です。
機能＃2。 法律の欠如
ソフトウェア開発、私見は、誤ってエンジニアリングに起因しています。 工学とは、科学技術の成果が適用される場所であり、特定の問題を解決して目標を達成するために自然科学の法則が使用されます。ニュートンの法則はソフトウェア開発でまだ発見されていません。ラグランジュの方程式はなく、少なくとも妥協はありません。これは、新しい重要なソフトウェアシステムの正しいアーキテクチャを設計および証明するのに役立ちます。 論理、情報理論、数値的手法、関係代数、グラフ理論、その他の分野の数学者の仕事は、産業用プログラミング問題の複雑さをカバーしていません。
優れたプログラマでさえ、新しいソフトウェアシステムのアーキテクチャが成功していると主張する自由を取りません。 プログラミングには既に障害の特定の経験が蓄積されていますが、これにより、洗練されたプログラマーは、新しいシステムのアーキテクチャのアンチパターンを見ることができます-深刻な将来の問題の原因。 しかし、それ以上ではありません。
Software Engineeringの現在の状態は、将来は決してない食材から料理を一度うまく準備するためのレシピの多くの説明を含む大きな料理本に似ています。 明日、新しいシステムは他のコンピューター、テクノロジー、プログラミング言語、ツール、周辺のソフトウェア、相互作用の新しい問題を解決する必要があります。
結果＃3。 プログラミングは技術です。
また、これは工芸品であるため、C ++でプログラムを書くことを学んだ人は、A.S。プーシキンまたはF.M.ドストエフスキーからロシア語で書くことを学んだ高校3年生のように、専門家からもかけ離れています。 クラフトの習得への道は、経験を通してのみあります。 本を読んでソフトウェア製品を開発する方法を学ぶことはできません。
当然の結果＃4。 自由はプログラマーの仕事の前提条件です。
オープンな法律がないため、プログラミングの問題のほとんどの解決策は試行錯誤によって発見されます。 プログラマは間違いを犯す権利を持っている必要があります。 これは、クリエイティブ検索の通常の属性です。 間違いから学ぶ。 スマートなのは間違いを犯さない人ではなく、間違いを繰り返さない人です。
自由の要素の1つは、タスクの締め切りが厳しいことです。 プロのマネージャーにとって、厳しい締め切りがないことはナンセンスに聞こえるかもしれませんが、創造的な活動においてこれは重要な要素の1つです。 プログラマーにもっと仕事をさせ、残業ラッシュの仕事や就業日を手配することは無意味です。 もっと働き、それはまったく意味がありません-より生産的に働きます。 むしろ、反対。 過度の圧力と大騒ぎは、誤った判断や多くの後続処理につながります。
機能＃3.視覚化ツールの欠如
ソフトウェア製品については、適切な視覚化ツールがまだ用意されていません。 ブルックスはこれについてほぼ40年前に話した。 したがって、ソフトウェア開発者は、しばしば仏教のたとえ話からの盲目の僧toに例えられます。
系譜5。 開発参加者の継続的なコミュニケーションの必要性。
経験から。 平均すると、ソフトウェア開発プロジェクトの各参加者は、あらゆる種類の会話に作業時間の50％を費やします。 これを「メンタルモデルの同期」と呼びます。 言葉、音色、およびイントネーションは、情報の半分未満しか送信しないことが知られています。 そのため、リモートチームメンバーへの情報の送信に2倍の時間が費やされます。 業界固有のCOCOMO II方法論は、プロジェクトが分散チームによって実行される場合、その複雑さを1.5倍する必要があることを教えています。
帰結＃6。 EQはIQよりも重要です。
対話と効果的な相互作用、推論、質問、回答の分析、紛争状況で相互に有益な解決策を求める能力、チームファイターの必須の品質。 人の創造性と有効性は、感情的知性（EQ）のレベルと、決定、意志、共感、直観、およびヒューリスティックな判断を行う能力に責任がある右半球の活動に依存します。
EQが不十分な場合は、絶望しないでください。 若年層で形成され、その後ほとんど変化しないIQとは異なり、EQは一生を通じて増加できます。
おわりに
集合的なプログラムによる創造性の場合、長編映画や演劇の作成との類似性が適切である可能性が高くなります。 これらの分野で失敗したプロジェクトの数は、プログラミングの場合と同じだと思います。 映画の少なくとも3分の1が最初のスクリーニング後に「棚に行く」ことができない場合、神は禁じられています。
そして、映画に関連するソフトウェアプロジェクトを作成するもう1つのことです。 最も優秀な俳優でさえも、映画の成功を保証するものではありません。 才能のある監督だけが、俳優を組織し、刺激して傑作を作り、新しい星を発見することができます。 残念ながら、才能のあるディレクターと才能のあるプログラムマネージャーは、私たちが望むほど多くはありません。