「優秀なプログラマは、平凡なプログラマの10倍の生産性を発揮できます」[非公開]

私は偉大なプログラマー（英語ではない）とのインタビューを読んだことがあり、その中で彼は「優秀なプログラマーは平凡なプログラマーの10倍も良い」と言っていました。プログラミング会社は従業員に多くの施設を提供しています。上記の理由により、優秀なプログラマーには非常に大きな需要があるという考えがありました。そのため、企業はそれらをもたらすために多くのお金を払っています。

この声明に同意しますか？それを裏付ける客観的な事実を知っていますか？

編集：質問は経験とは関係ありません。1年の経験を持つ優れたプログラマーについて話す場合、1年の経験を持つ平凡なプログラマーよりも生産性が10倍高いはずです。私は、特定の経験年以降、物事は散逸し始めますが、それは質問の目的ではないことに同意します。

生産性の違いに関する調査のかなり徹底した概要と分析は、Steve McConnellが執筆した2つの記事で提供されています。

• ソフトウェア開発者とチーム間の生産性の違い：「10x」の起源

• 10Xの起源–基礎研究はどの程度有効ですか？

最初の記事（生産性の変化...）状態：

...個々のプログラミングの生産性に大きなばらつきがあることを発見した最初の研究は、1960年代後半にSackman、Erikson、およびGrant（1968）によって実施されました。彼らは平均7年の経験を持つプロのプログラマーを研究し、最高のプログラマーと最悪のプログラマーの間の初期コーディング時間の比率は約20対1であることがわかりました。25対1を超えるデバッグ時間の比率。プログラムサイズ5から1。また、プログラムの実行速度は約10対1です。プログラマの経験とコードの品質または生産性との間に関係はありませんでした。

Sackman、Erickson、およびGrantの調査結果を詳細に調べると、それらの方法論にいくつかの欠陥があることが示されています...

当初の研究以来、「プログラマーには桁違いがある」という一般的な発見は、プロのプログラマーに関する他の多くの研究によって確認されています（Curtis 1981、Mills 1983、DeMarco and Lister 1985、Curtis et al。1986 、カード1987、Boehm and Papaccio 1988、Valett and McGarry 1989、Boehm et al 2000）...

^{この記事には興味深い副次的な注意事項もあります。}

^{この程度のばらつきは、ソフトウェアに固有のものではありません。Norm Augustineの調査によると、さまざまな職業（執筆、サッカー、発明、警察、その他の職業）で、人々の上位20％が出力の50％を生み出しました。 、解決済みのケース、またはソフトウェア（Augustine 1979）。}

第二に、物品（？...基礎研究はどのように有効ですが）による最初の1の批評に対処するために主に書かれていローランBossavitを：

• フランス語のオリジナルの批評：Folklore ou fait scientifique、comment lesdifférencier
• 英語翻訳：ソフトウェアエンジニアリングの事実と伝承。

2番目の記事のセクションAの「10x」 McConnellをサポートする研究の詳細では、最初の記事で使用されたリファレンスをより詳細に再確認し、結論を出します。

...この記事を執筆する際にこれらの引用をもう一度検討したとき、プログラマーの間で生産性に10倍の違いがあるという一般的な発見を支持していると改めて結論付けました。これらの研究には、プログラミング活動の範囲全体で数百人のプロのプログラマーが参加しています。

... 10xの主張を裏付ける研究機関は、ソフトウェアエンジニアリングで行われた研究と同じくらい堅実です。10xクレームをサポートする研究は、個々の変動自体（つまり、図の左側のみ）を研究しているため、図1で説明されている方法論的な制限の対象にはなりません。Bossavitは、10倍の主張に反する1つの研究（欠陥のあるものを含む）を引用しておらず、そのような研究も見たことがありません。10xクレームと矛盾する調査結果を出した研究がないという事実は、10xクレームに対する信頼性をさらに高めます。これまでに行われた研究の数を考えると、研究は示唆に富むだけでなく、決定的なものであることがわかりました。これはソフトウェア工学研究ではまれです。

完全を期すために、生産性のバリエーションで使用される参照のリストも以下に引用します。

参照資料

オーガスティン、NR1979。「オーガスティンの法と主要なシステム開発プログラム。」防衛システム管理レビュー：50-76。

Boehm、Barry W.、およびPhilip N. Papaccio。1988.「ソフトウェアコストの理解と管理。」IEEE Engineering on Software Engineering SE-14、いいえ。10（10月）：1462-77。

Boehm、Barry、et al、2000。マサチューセッツ州ボストンのCocomo IIでのソフトウェアコストの推定：Addison Wesley、2000。

Boehm、Barry W.、TE Gray、およびT. Seewaldt。1984.「プロトタイピングと指定：マルチプロジェクト実験」。IEEE Engineering on Software Engineering SE-10、いいえ。3（5月）：290-303。ジョーンズ1986bでも。

カード、David N.1987。「ソフトウェア技術評価プログラム。」情報およびソフトウェア技術29、いいえ。6（7月/ 8月）：291-300。

カーティス、ビル。1981.「プログラマーのばらつきを実証する」。IEEE 69の議事録、いいえ。7：846。

カーティス、ビル、他 1986年。「ソフトウェア心理学：学際的プログラムの必要性。」IEEE 74の議事録、いいえ。8：1092-1106。

デマルコ、トム、およびティモシーリスター。1985.「プログラマーのパフォーマンスと職場の影響」。ソフトウェア工学に関する第8回国際会議の議事録。ワシントンDC：IEEE Computer Society Press、268-72。

DeMarco、Tom and Timothy Lister、1999。Peopleware：Productive Projects and Teams、2d Ed。ニューヨーク：ドーセットハウス、1999年。

Mills、Harlan D.1983。ソフトウェア生産性。マサチューセッツ州ボストン：リトル、ブラウン。

サックマン、H、WJエリクソン、EEグラント。1968.「オンラインとオフラインのプログラミングパフォーマンスを比較する探索的実験研究。」ACM 11の通信はありません。1（1月）：3-11。

Valett、J。、およびFE McGarry。1989.「ソフトウェアエンジニアリングラボでのソフトウェア測定経験の要約。」Journal of Systems and Software 9、いいえ。2（2月）：137-48。

ワインバーグ、ジェラルドM.、エドワードL.シュルマン。1974.「コンピュータープログラミングの目標とパフォーマンス。」ヒューマンファクター16、いいえ。1（2月）：70-77。

本当にひどいプログラマーは、生産性が氷点下になる可能性があります（彼らが導入するバグは、彼らのためにすべての仕事をするよりも修正に時間がかかります）。

そして、本当に優れたプログラマーは、どれだけの時間を与えても、貧しいプログラマーや平均的なプログラマーが決して達成できないことを行うことができます。

したがって、これらの理由から、「生産性として10倍」または「生産性として100倍」について語るのは困難です。

しかし、覚えておくべきことは、ほとんどのプログラマーの雇用主は、平均的なプログラマーが管理できない困難なタスクを実行する必要がないことです。記述されているコードのほとんどは、Webサイト、基幹業務アプリ、イントラネットアプリなどです。その多くはそれほど難しくありません。その環境で生産的なプログラマーは、ユーザーのニーズを理解して実装するのに最適な人であり、最も賢いコードを書くことができる人ではありません。

確かに、プログラマーのほとんどの雇用主は、優れたプログラマーよりも優れたプログラマーのほうが良いでしょう。なぜなら、偉大なプログラマーは退屈して去るからです。プログラマーと仕事の間の良い一致を見つけなければなりません。

ソフトウェアエンジニアリングの状態の事実と誤り（事実2、Amazonプレビューで利用可能）：

「個人差」調査によると、最高のプログラマーは最悪のプログラマーよりも最大28倍優れています。彼らの賃金が決して釣り合っていないことを考えると、彼らはソフトウェア分野で最大の掘り出し物です。

（研究のためにそこのソースリストを見てください）

もちろん、非プログラマー（または非常に悪いプログラマー）の生産性を（経験と知識の面で）良いプログラマーと比較すると、その差は無限に大きくなる可能性があります（n/0 == infinity肯定的な場合n）が、公平ではありませんまた賢明な比較。

給与は複数の要因に依存する場合があります（ランダムな順序）：

• 使用される技術
• 勤務先の国/州
• 会社の富
• 会社の業種
• 社内の開発者数
• 会社でどれくらい働いていますか
• オフィス政治

あなたの個人と一緒に...

• 生産性
• 知識と経験
• 会社のビジネスへの関与（スタートアップ向け）
• 交渉スキル
• 性的魅力とスキル、笑（まあ、知性はセクシーです）

私の答えは「はい、しかしそのメトリックをどのように使用するかに注意してください」です。

最適に機能しているプログラマーは、機能のために作成し、パフォーマンスの低い兄弟よりも修正が必要なエラーが少ないプログラマーです。これらの人々が他の人々の生産性を10倍で発揮できると信じることは難しくありません。特に、1時間で行った良い選択または悪い選択が10時間の影響を容易に受け、プログラマーが多くの選択を行うと考える場合ほとんどの日。

しかし...

これを測定する際には注意が必要です。ほとんどすべての既知のメトリックがチームの生産性に不可欠であると考えるものを考慮に入れないという無限のケースを見てきたので、生産性に関するほとんどの測定値を本当に信用していません。だから私は一般的に「生産性」のためにそのようなハードな数字を嫌います。以下に例を示します。

• コード行（LOC）-一般的に嫌われているメトリック。思慮のないプログラマーは多くの恐ろしく、冗長で、非効率的でデバッグが難しいコード行を生成できるのに対し、優秀なプログラマーは少数のエレガントで修正しやすい、まれに壊れたコード行を作成できるより多くの時間で、しかし全体的に良い選択です。
• 生成されたバグおよび/または修正する時間-誰もがいくつかのバグを生成し、多くの場合、最も高価なバグは、問題の発生者がドミノ効果の最後にすぎない一連の悪い決定によって生成されます。また、優れたデバッガーが優れたデザイナーであるとは限りません。両方が必要です。
• ほぼすべてのメトリックで、チームに苦労している優秀な開発者がいます。1人の「非常に生産的な」開発者が10人の基本的に優秀な開発者を追い払うので、私は私たちが必要とすることはめったにありませんプロジェクトに1人以上。
• 特に問題がプロセスのギャップである場合-問題のあるCM、非効率的なビルド、テストのギャップ、セキュリティの欠陥-これらの問題が深刻になる前に来る問題を見て、それらに立ち向かう素晴らしい人々を簡単に説明する方法はありません災害からあなたを救うことに気付くまで、多くの場合、時間の大きな無駄のように見えます。それを測定する方法はありません。
• また、私が「結束ビルダー」と呼ぶ特定の規模のチームに必要だと考える人々がいます-生産性の絶対的なトップになることはめったにありません。彼らは通常、まだ20％を超えており、立ち上げを支援する非常に貴重な仕事をしています新しい人たち、点をつなぎ、正しい質問が出され、正しい人がループにとどまることを確認して、彼らは正しいドキュメントだけでなく、誰もが参照する重要なドキュメントを書きます（聞きません！）正しい方法で組み立てられています。10人を最高の効率で働かせたい場合、これらの人々の1人が絶対に必要であり、10人のスーパー開発者を部屋に置いた場合、それを得ることができません。

多くの測定システムはこれらの要因を考慮に入れようとしましたが、これらの問題すべてを考慮に入れたものがあることをまだ見ていません。そのため、「優れた開発者はメトリックが本当に成功している進行中の製品または成功し、繁栄しているチームに入るために必要なすべての作業を考慮しているのか疑問に思う必要があるからです。

それで、私の大きな警告は-このメトリックで何をするつもりですか？このようなものを使用して、適切なツールと才能が仕事の遂行方法に大きな違いをもたらす可能性があることを認識しますが、各個人が10倍の「典型的な」出力を生成するチームに最適化しようとすると、欲求不満の場合。より良いのは、チームをより良く働かせることで、チームが以前やっていたことを2-3倍にする方法を見つけることです。

Laurent Bossavitは、著書The Leprechauns of Software Engineeringで、生産性に関する10倍の主張の研究について説明しています。彼はその背後に健全な数字がないことを発見しました- 主張は、引用で連続してより具体的な主張の電話ゲームによって推測から「確立された事実」になりました。10xクレームに関する章で構成され、関連する引用と誤引用を含むブログ投稿は、ソフトウェアエンジニアリングの事実と民間伝承です。

彼が見つけたのは次のようなものです。1968年に誰かが特定のデバッグ問題を解決する人々を比較する研究を行い、一部の人々は他の人々より10倍速くそれを見つけたことがわかりました。このことから、一部の人々はその問題を解決するのに10倍優れていると結論付けることができます。また、一部の人々は幸運に恵まれた、または多種多様なことを結論付けることができます。一部の人々はこれを引用することを選択しました（これらはすべて換言です）「ある研究（Sackman et al、1968）は、あるプログラマは他のプログラマよりも10倍速く動作することを発見しました」。その後、「優れたプログラマは平均よりも10倍優れていることを研究が示した」、そして最終的には「プログラマの生産性が個人間で10倍異なることはよく知られています」になりました。次に、誰かがこれらの引用をすべて収集し、1つの元のソースを誤って引用します 「多くの研究者が信じている…」と言う。

もちろん、アサーションの信only性のみが変更された場合、電話ゲームではありません。乗数は11以上になります。

「その環境での生産的なプログラマは、ユーザーのニーズを理解して実装するのに最適な人であり、最も賢いコードを書くことができる人ではありません。」（Carson63000の回答より）

ベツラクシュミと結びついたそのキーポイントのポイントが大きなポイントになります。優れた開発者は、自分の現実の一部で優れていることができますが、世界が変わるとすぐにバラバラになります。ビジネスのニーズに対応できることは、他の何よりもはるかに重要です。結局のところ、ビジネスがテクノロジーでない限り、ビジネスはテクノロジーを気にしません。彼らには解決策が必要です。そのため、デザインパターンが優れているということは、Webページに表示するためにデータダンプを必要とするだけのエンドユーザーにうっかりしゃがむことを意味しません。優秀な開発者が飽きることなく果てしない挑戦を求めて立ち去りながら、平凡な開発者が彼らをサポートするビジネスに対応することで仕事を確保するのを見てきました。組織やプロジェクトによっては、これらの課題に飢えた開発者にフィードを提供することも可能ですが、おそらくそうしない場合があります。その量の処理能力が必要です。これらの開発者は、プロセッサのようにただじっと座っているのを好みません。他の場所でシャットダウンして再起動します。

最後に、「キー」パフォーマーが誰であるかを知っていてもかまいませんが、開発「チーム」は依然としてチームです。ベスラクシュミを繰り返すために、「このメトリックで何をするつもりですか？「チームのように振る舞うチームが必要な場合、これらのような指標に焦点を当てません。最小のプレーヤーでさえチームの重要な部分であることに気づきます。キーの生産性が60％低下してもあるプレイヤーがあなたのチームに必要なものを与えているかもしれません。それが何であるかを見つけて、それを増やそうとします。チームをリードすべきだと思い込んでキープレイヤーを燃やさないでください。他のプレイヤーをその偉大さで汚染します。これには、数字だけではなく、少しの創造性が必要です。またはそれもあなたかもしれません。