プログラミング、高速および低速：開発者と自信の心理学

今日は、ソフトウェア開発者が予備的な計算を行う瞬間に何が起きているのかについてお話します。 彼らが頭の中ですべてのアイデアを修正することがとても難しい理由について。 また、この状況を自分自身でどのように解決し、ソフトウェアをどのように作成し（幸せなビジネスオーナー向けに）作成するかについても学びましたが、複雑さについての私自身の見積も​​りはこれまで以上に信頼できません。



しかし、最初に、物語...



私が若い開発者だったとき、<私はばかげて年をとらない期間を挿入しました>（1）。 大学では、私はプログラミングクラスで最高の経験を持ち、ジュニア開発者として、コードを解読し、誰よりも早く設定されたタスクを解決することができました。 週末には、新しい言語を学び、その言語で生産的に作業することができました（または、少なくとも、それは私には思えました）。



したがって、それが起こるはずだったように、私は自分のプロジェクトを持っていました。 大規模なクライアントを扱うマネージャーは、クライアントが何を望んでいるかを一般的な言葉で説明してくれたので、「この作業には3週間かかります」と答えました。 そしてプログラミングを始めました。



このプロジェクトにどれくらい時間がかかったと思いますか？ 4週間？ たぶん5？



うーん、実際：3か月。



その時の明確な思い出がありました-私自身の私の考えは、私が「良いプログラマー」であるという感覚と密接に関連していました。 私は睡眠を失い、軽度のパニック発作を起こしました。 そして、これは終わりではありませんでした。 私はそのマネージャーと話をしているときにお腹を吸っていたことを覚えています。



これらの黒い時期の1つで、私は二度と同じような間違いをしないと決めました。



残念ながら、私のキャリアの中で、私は非常に難しいことに気付きました。私は常にそのような過ちを犯します。



実際、私はもっと良いことさえ学んだ：私たちは皆これらの間違いを犯す。



最近、ダニエル・カーネマンの著書「 Thinking、Fast and Slow 」を読みました。心理学が人の認知プロセス、彼の驚くべき長所、および（驚くほど予測可能な）弱さについて知っていることに関する広範な研究です。



私の好きな部分は自信です。 たとえば、開発者が計算を行う方法との関係を示しました。

なぜ計算が悪いのか、パートI：ソフトウェアの作成=まだ知らないことを知る

そもそも、実際には、計算が非常に悪い理由は2つしかないと思います。 最初の理由は、改善の余地がありません。ソフトウェアを書くことは、コンピューターにそれを行う方法を説明できるように、非常に正確な詳細を記述する方法を理解する必要があるプロセスです。 しかし問題は、仕事の初期段階であなたが完全に理解していない部分には、出て来てあなたをひどく傷つける困難があるということです。



そして、改善することはまったく不可能です。 そして、あなたが本当に「何をすべきかを完全に理解している」場合、またはあなたがライブラリを持っているか、あなたのためにこれを行うことができるソフトウェアがあれば、あなたは何も書きません。 そうでなければ、未知のものが現れ、しばしば爆発します。 そして、これらの問題を解決するのにどれくらい時間がかかるのか、おそらく1日、1年、あるいは宇宙の熱死の前に十分な時間がないかもしれません。



たとえば、開発側からの関与者の一部が信頼できないことが判明した場合は、エラーを含む配列全体を書き換える必要があります。 または、データベースがエンコーディングのいくつかの重要な部分を理解していない場合...すべてのスキームをゼロから再構築する必要があります; または、あなたが仕事をクライアントに見せても、彼らが注文したものを受け入れないが、少し違うものを望んでいるとき、ジャンルの本当の古典です...それは何倍も難しいです。



このような困難に最初に遭遇したとき、「これからは、仕様開発の段階でより注意を払う必要がある」と考えます。 しかし、これは良い考えではありません。 なんで？ 主な理由は、上記の例からわかるように、これらのすべての事故を考慮に入れて仕様を詳細にコンパイルすると、実際にソフトウェアを書いていることが判明するからです。 そして、実際、この問題を解決する方法はありません（この記事を読んでいるときに、あなたがこの声明に挑戦しようとしているなら、私はあなたに伝えます-正確に、絶対に、方法はありません。完全な仕様は理想的な経済的アイデアです。収益性の高い、経済的な観点から、オプション）。

しかし、ここからが楽しみです。 現実の世界で数か月以上働いたすべてのプログラマーは、上記の問題に遭遇しました。



それでも... ...私たちはそのような印象的なほど貧弱な計算を続けています。



さらに悪いことに、私たちは私たち自身の計算を信じています。 私自身は、私がそれらを生産する瞬間に自分自身を信じています。



それでは、すべての開発者がとにかく同じ予測可能な思考エラーの犠牲になることを何と言っていますか？



はい、これはまさに私が提供するものです。

計算が成功する理由パートII：自信

カーネマンは、「専門家」が予測を立てる問題について多くのことを語っています。 驚くほど多種多様な状況では、これらの予測はまったく役に立ちません。 特に、非常に多くの状況では、次の3つのステートメントが当てはまります。



1-将来のイベントに関する「専門家」の予測は信頼性が低いため、本質的に意味がありません。



2-しかし、議論された専門家は、彼らの予測の正確さに非常に自信を持っています。



3-そして何よりも素晴らしいことは、専門家のこの自信感を軽視することは絶対にできないように思われることです。



そして、最後の声明は、専門家が正直に自分の失敗に直面しようとしても、たとえ人間の思考の欠如に深く気づいていたとしても...彼らは予測の正確さに深く自信を持っているという、本当に際立った声明です。



カーネマンは、この分野での彼自身の失敗について驚くべき話をした後、それをどのように説明するかです：

「将来の判断で感じる自信は、たとえすべての単語を信じていたとしても、今読んだものによって軽視されることはありません。」



おもしろいのは、専門家の予測がかなり良い状況があることです。これらの状況と、それらを使用して開発プロセスを改善する方法を以下に示します。 しかし、これを行う前に、誤った自信がどのように機能するかの詳細を調べたいと思います。実際には、あなたは自分でそれを見つけることができるかもしれません。

自分が間違っていると感じるのはどのようなものか：システムIとII、および3週間と3か月の問題

「思考の高速化と低速化」で、カーネマンは、心理学のほとんどを、私たちの思考を制御する2つの「システム」、システムIとシステムIIの間の相互作用として説明しています。 これについての私の非常に短い要約は次のとおりです。「システムIIは正確、合理的、分析的思考に責任があり、システムIは高速、ヒューリスティック、および比較思考に責任があります。」



そして重要なことは、System IIがあまり多くのことをする必要がないように、進化がすべてを1つの目標で設計したように見えることです。 進化の観点からすると、これは非常に論理的です。システムIIは糖蜜のように遅く、非常に高価なので、非常にまれなケースで使用する必要があります。 しかし、あなたは問題を、疑いもなく、あまり考えずに見ます。それでは、System IIを起動するタイミングをどのように理解する必要がありますか？ この観点から、心理学のさまざまな「認知のゆがみ」の多くは、リアルタイムでの注意の分散などの残酷な生活の問題に対する洗練された工学的解決策として認識できます。



システムIとIIの相互作用がいかにひどい、そして正直で信頼できる計算につながるかを確認するために、マイクを友人（およびHut8Labsの同僚） Edmund Jorgensenに簡単に転送します。 彼はこれを彼の手紙の中で次のように説明してくれました。



「このプロジェクトにどれだけの時間を費やすか」と自問したとき、システム私はそれについては知りませんでしたが、答えを得たいと思い、質問をトランスコードしました。 何時？ 「これができると確信している限り」のようなもので、これは特定の係数を使用した時間計算に変換されたと思われます。これは相対値です（たとえば、Bobが学位を感じたとき） Xの自信、彼は常に3週間応答します。スージーがXの自信を感じると、彼女は常に5週間応答します。



2つの「大きな」タイムメーターがあることに徐々に気づいたら、手を挙げてください。 たとえば、私にとっては「3週間」と「3か月」です。 1つ目は、「複雑に思えますが、基本的にはどのように行うかを知っていると思います」ということです。 2つ目は、「うわー、これは難しい。何が必要かはよく分からないが、理解できるはずだ」



ああ、エドマンドは完全に正しいと思う。



（家で遊ぶ人のために：私の「3週間」プロジェクトはおそらく5-15週間かかりますが、私の「3か月」プロジェクトは通常1-3年かかります。 ）

いいね！ さあ、自信を失いましょう！

この観点から考えることができます：「まあ、行きます、ダン、システムIではなくシステムIIの原則に従ってこれらの計算にアプローチする必要があります。したがって、慎重で分析的な心がより良い計算を行います。」



おめでとうございます、あなたはちょうど滝を発明しました。



本質的に、これは「プログラミングを開始する前に完全な仕様をコンパイルする」アプローチのアプリケーションです：チームに直感的な計算をさせず、全員に分析能力を慎重に動員させ、詳細な仕様と計算を小さな部分に分割してソリューションにアプローチさせます。



ただし、これは失敗する運命にあります。 いつものように...



ここでの本当の問題は、誤った測定の2つの原因の間の相互作用です。1つは自信に関連するヒューマンエラーであり、もう1つは実際のソフトウェア作成プロジェクトに固有の不確実性の固有要素です。 この不確実性は非常に深刻で、きちんとした合理的なシステムIIでさえ正確な予測を提供することはできません。



幸いなことに、思考の長所を組み合わせて使用​​すると同時に、現実世界の非永続性に対処する方法があります。



まず、あなたの思考の強みをどのように使うか。

いつエキスパートが正しいか、そしてそれをどのように活用するか

カーネマンと他の研究者は、専門家の判断が完全に誤りではない状況を特定できました。 彼によると：



「特定の直感的な判断を信頼できるかどうかを確認するには、2つの質問をする必要があります。判断が行われる環境は、利用可能な証拠に基づいて予測を行うのに十分なものですか？ 答え「はい」は診断用、「いいえ」はストックピッカー用です。 専門家は信号とパターンを研究する機会がありますか？」



「対応する機会」とは、多数の完全な予測と、その正確性を調査するための綿密なフィードバックを意味します。



現在、6〜18か月のソフトウェア作成プロジェクトでは、これらのすべての基準を完全に満たしていません。 先ほど言ったように、環境は「永続的」ではありません。 さらに、専門家には組み合わせがありません。多くの予測を立て、迅速なフィードバックを得ることができます。 何かが1年以上かかる場合、フィードバックが長すぎて直感を訓練できません（さらに、多数の例が必要になります）。



ただし、ソフトウェア開発に適用できる適切な決済の形式があります-すぐに実装される場合、0〜12時間のタスク。 この角度から、物事は異なって機能します：

• まだ多くの事故がありますが（詳細については以下を参照）、「環境の恒常性」への希望が残っています。 2つの2時間タスクには、2つの6か月プロジェクトよりも多くの共通点があります。
• 数年にわたって何百もの同様の計算を行うことを想像できます。
• 計算の精度に関する非常に迅速なフィードバックが得られます。

私が最も働いていたチームは毎週スプリントを実施し、すべてが0、2、4、または8時間に分割されていました（そして8時間のタスクには常にいくつかの不信がありました-どういうわけか、私たちはそれらをより小さなセグメントに分割しようとしました） 私たちはそれらを非常に迅速に計算し、何らかの理由で偶然に計算しました。このため、 ポーカープランニングのペダンティックテクニックも使用しませんでした。



この観点から、システムIの長所を活用します。システムIをトレーニングでき、多くの例があり、選択できる意味のあるモデルが含まれています。 そして、短いスプリントのおかげで、計算の質に関して非常に迅速にフィードバックを得ることができます。

停止、停止、停止！ 4時間ごとに1,000回の計算を行いましょう！

これらの微計算を行うことはできますが、どういうわけか6〜18か月前の計算に適用することはできません。 エラー値は平均化されていませんか？



基本的に、このようなスケールでの計算は通常正しいと思いますが、正しくない場合は、どれだけ間違っているかに制限はありません。 数学的に言えば、実時間はべき乗則の分布に従うと思われます。 また、べき法則の分布は、安定した値と無限の分散を持たないことで知られていますが、率直に言って、大きな滝の設計と同じ計算のようです。



あなたは考えるかもしれません：4時間でできることは1〜2ヶ月かかる可能性さえありますか？



これは常に起こります。最終段階に行こうとしていますが、突然、いくつかの隠れた障害が根本的にすべてを変えることがわかります。 たとえば、最近のスタートアップでは、システムの特定のエラーを修正しようとしたときに、作成したIMAPサーバーの前にロードバランサーを配置しました。 そのため、あるサーバーがクラッシュした場合、ロードバランサーはプロセスを別のサーバーにスムーズに転送し、クライアントは何も感じません。



そして、私たちには4時間のタスクのように思えました。



しかし、私たちがその場所に着いたとき、私たちは慣れているHTTPサーバーとは異なり、IMAPサーバーが接続状態を使用することを認識しました。 トランスペアレントモードでバックアップサーバーに切り替える場合は、2台のサーバーで接続状態を管理するか、接続状態を担当し、IMAPサーバーの前にインストールされるプロキシロードバランサーを記述する必要があります。



3か月のプロジェクトと思われたもの（2）。



ショートスプリントがこのすべての鍵であるもう1つの理由は、ひどく誤った計算の価格に厳しい制限を設けていることです。

私たちは完全なお尻にいますか？

それで、私たちは何をしますか？ すべてのプロジェクトが失敗する運命にあることを受け入れます。 私たちは約束を果たすことができないため、残りの顧客との関係を破ることになりますか？



解決策は、正確な長期計算を行うことが基本的に不可能であるという事実を最初に受け入れることです。 これに気づいたら、次のタスクを引き受けることができますが、処理は非常に困難です。開発チームが多かれ少なかれ長期的な計算を行うことができないとしても、どうやって大量の値を生成することができますか。



基本的には、世界がさまざまなアジャイル開発方法論を採用した理由の最初の原則の説明です。 これについては、次のトピックで詳しく説明します。「プロジェクトの期限はありません。 あなたがあなたの義務を果たしていないときでさえ、顧客にあなたを愛させる方法。」



1.（グループは<日付の付いた音楽リンクを挿入>をラジオで再生し、全員が<長い間忘れられていたテレビ番組>について話し合っていました。

2.「1分間待って、3か月の計算の1つとして3か月はどうですか？」と思ったら、何を言っているのかわかりません。



トルストイサマーキャンプスタートアップスクールの一環として翻訳