「優れたプログラマーは、平凡なプログラマーの10倍の生産性を実現できます。」
私は優秀なプログラマー（英語ではありません）とのインタビューを読みました。その中で彼は、「優秀なプログラマーは平凡なプログラマーの10倍の能力がある」と述べ、優れたプログラマーは非常に高い給与を支払う理由と理由を説明しました。プログラミング会社は、従業員に多くの設備を提供しています。上記の理由により、優れたプログラマーには非常に大きな需要があるという考えでした。そのため、企業はそれらをもたらすために多額の費用を払っています。
この声明に同意しますか？それをサポートできる客観的な事実を知っていますか？
編集：問題は経験とは関係ありません。 1年の経験を持つ1人の優れたプログラマについて話す場合、その人は1年の経験を持つ平凡なプログラマよりも10倍生産性が高いはずです。私はある年の経験から、物事は消散し始めますが、それが問題の目的ではないことに同意します。
Steve McConnell が執筆した2つの記事では、生産性の違いに関する研究のかなり完全な概要と分析が提供されています。
最初の記事（生産性の変化...）は次のように述べています：
...個々のプログラミングの生産性に大きな変動を発見した最初の研究は、1960年代後半にSackman、Erikson、およびGrant（1968）によって実施されました。彼らは平均7年の経験を持つプロのプログラマーを調査し、最高のプログラマーと最悪のプログラマーの間の初期コーディング時間の比率が約20対1であることを発見しました。 25対1のデバッグ時間の比率。プログラムサイズは5対1。また、プログラムの実行速度は約10対1でした。彼らは、プログラマーの経験量とコードの品質または生産性との間に関係がないことを発見しました。
サックマン、エリクソン、グラントの調査結果を詳しく調べると、方法論にいくつかの欠陥があることがわかります。しかし、欠陥を考慮した後でも、彼らのデータは、最高のプログラマーと最悪のプログラマーとの間に10倍以上の違いを示しています。
最初の調査から数年、「プログラマー間に桁違いがある」という一般的な発見は、プロのプログラマーに関する他の多くの調査によって確認されています（Curtis 1981、Mills 1983、DeMarcoおよびLister 1985、Curtis et al。1986 、カード1987、Boehm and Papaccio 1988、Valett and McGarry 1989、Boehm et al 2000）...
この記事には興味深いサイドノートもあります。
この程度の変化はソフトウェアに固有のものではありません。Norm Augustineによる研究では、さまざまな職業（執筆、サッカー、発明、警察）で、仕事、およびその他の職業-出力がタッチダウン、特許、解決されたケース、ソフトウェアのいずれであっても、人々の上位20％が出力の約50％を生成しました（1979年8月）。
2番目の記事（...根底にある研究はどの程度有効ですか？）は、主に最初のレビューの批評的レビューに対処するために Laurent Bossavit によって記述されています。
- フランス語の元の批評： Folklore ou fait scientifique、コメントlesdifférencier
- 英語翻訳： ソフトウェア工学における事実と民間伝承 。
2番目の記事のセクションで、「10x」をサポートする研究の詳細McConnellは、最初の記事で使用された参照をより詳細に再チェックし、結論付けています。
...この記事を書いているときにこれらの引用をもう一度確認したところ、プログラマー間で10倍の生産性の違いがあるという一般的な発見を支持するものであると再度結論付けました。この研究には、さまざまなプログラミング活動にわたって、何百人ものプロのプログラマが集合的に関与しています。
... 10倍の主張を裏付ける一連の調査は、ソフトウェアエンジニアリングで行われたあらゆる調査と同じくらい堅実です。 10倍の主張を裏付ける研究は、個人の変動性自体（つまり、図の左側のみ）を研究しているため、図1で説明した方法論の制限の対象にはなりません。ボサヴィットは、欠陥があるかどうかにかかわらず、10倍の主張に対抗する研究を1つも引用していません。また、そのような研究は見たことがありません。 10xの主張に矛盾する調査結果が得られた研究がないという事実は、10xの主張に対する信頼をさらに高めます。行われた研究の数を考えると、全体として、この研究は示唆に富むだけでなく、決定的なものであることがわかります。これはソフトウェアエンジニアリングの研究ではまれです。
完全を期すために、生産性のバリエーションで使用される参照のリスト...も以下に引用されています。
参考文献
オーガスティン、N。R.1979。「オーガスティンの法則と主要なシステム開発プログラム」。防衛システム管理レビュー：50-76。
ベーム、バリーW.、フィリップN.パパッチョ。 1988.「ソフトウェアコストの理解と制御」ソフトウェアエンジニアリングSE-14のIEEEトランザクション、いいえ。 10（10月）：1462-77。
Boehm、Barry、他、2000年。CocomoIIを使用したソフトウェアコストの見積もり、マサチューセッツ州ボストン：Addison Wesley、2000年。
ベーム、バリーW.、T。E.グレイ、T。シーヴァルト。 1984.「プロトタイピングと指定：マルチプロジェクト実験」ソフトウェアエンジニアリングSE-10のIEEEトランザクション、いいえ。 3（5月）：290-303。ジョーンズ1986bにも。
カード、デビッドN.1987。「ソフトウェア技術評価プログラム」。情報およびソフトウェア技術29、いいえ。 6（7月/ 8月）：291-300。
カーティス、ビル。 1981年。「プログラマの多様性の実証」。 IEEE 69の議事録、いいえ。 7：846。
カーティス、ビル、他1986.「ソフトウェア心理学：学際的プログラムの必要性」 IEEE 74の議事録、いいえ。 8：1092-1106。
DeMarco、Tom、およびTimothy Lister。 1985.「プログラマーのパフォーマンスと職場の影響」ソフトウェアエンジニアリングに関する第8回国際会議の議事録。ワシントンD.C .: IEEE Computer Society Press、268-72。
DeMarco、Tom and Timothy Lister、1999。Peopleware：Productive Projects and Teams、2d Ed。ニューヨーク：ドーセットハウス、1999年。
ミルズ、ハーランD.1983。ソフトウェア生産性。マサチューセッツ州ボストン：リトル、ブラウン。
サックマン、H.、W.J。エリクソン、およびE. E.グラント。 1968.「オンラインとオフラインのプログラミングパフォーマンスを比較する探索的実験的研究。」 ACM 11の通信、いいえ。 1（1月）：3-11。
バレット、J。、およびF. E.マクギャリー。 1989.「ソフトウェア工学実験室におけるソフトウェア測定経験の要約」システムとソフトウェアのジャーナル9、いいえ。 2（2月）：137-48。
ワインバーグ、ジェラルドM.、エドワードL.シュルマン。 1974年。「コンピュータプログラミングの目標とパフォーマンス」。人的要因16、いいえ。 1（2月）：70-77。
本当にひどいプログラマは生産性がゼロ以下になる可能性があります（彼らが導入するバグは、すべての作業を行うだけの場合よりも、修正に時間がかかります）。
そして、本当に優れたプログラマーは、どれほどの時間を費やしたかに関係なく、貧弱で平均的なプログラマーがneverで達成できることを簡単に実行できます。
したがって、これらの理由から、「10倍の生産性」または「100倍の生産性」について語ることは困難です。
ただし、覚えておくべきことは、プログラマーのほとんどの雇用者は、平均的なプログラマーでは管理できない困難なタスクを実行する必要がないということです。記述されているコードのほとんどは、Webサイト、基幹業務アプリ、イントラネットアプリなどですが、その多くはそれほど難しくありません。その環境で生産的なプログラマーは、ユーザーのニーズを理解して実装するのが最も得意な人であり、賢いコードを書くことができる人ではありません。
実際、プログラマーのほとんどの雇用者は、優れたプログラマーよりも優れたプログラマーの方が良いでしょう。お奨めは、プログラマーと仕事の間の良い一致を見つけます。
ソフトウェア工学の事実と誤り 状態（事実2、Amazonプレビューで利用可能）：
「個人差」の調査によると、最高のプログラマーは最悪のプログラマーよりも最大28倍優れています。彼らの給料が決して釣り合っていないことを考えると、彼らはソフトウェア分野で最大の掘り出し物です。
（研究のためにそこに出典リストを見る）
もちろん、プログラマーではない（または非常に悪いプログラマー）と（経験と知識の点で）優れたプログラマーの生産性を比較すると、その差は無限に大きくなります（n/0 == infinityは任意の正のn）ですが、公平でも分別のある比較でもありません。
あなたの給与は複数の要因に依存する場合があります（順不同）：
- 使用されているテクノロジー
- 勤務している国/州
- 会社の富
- 会社の業種
- 社内の開発者数
- 会社でどのくらい働いていますか
- オフィス政治
あなたの個人と一緒に...
- 生産性
- 知識と経験
- 会社の事業への関与（スタートアップ企業向け）
- 交渉スキル
- 性的魅力とスキル、笑（まあ、知性はセクシーです）
私の答えは「はい、しかしその測定基準の使い方には注意してください」です。
最適に機能しているプログラマーとは、機能性のために作成し、パフォーマンスの低い兄弟よりも修正が必要なエラーの発生が少ないプログラマーです。これらの人々が他の人々の10倍の生産性を発揮できると信じるのは難しいことではありません。特に、1時間に行われた単一の良いまたは悪い選択が容易に10時間の影響を与え、プログラマーがそのような多くの選択をすることを考える場合ほとんどの日。
だが...
これを測定する際には注意が必要です。ほぼすべての既知のメトリックがチームの生産性に不可欠であると考えるものを考慮できない無限のケースを見てきましたので、私は生産性に関するほとんどの測定値を本当に信頼しません。したがって、私は一般的に、「生産性」のそのような難しい数字を嫌います。ここにいくつかの例があります：
- コード行（LOC）-一般に嫌われている指標です。無頓着なプログラマーは、コード行を恐ろしく冗長で非効率的でデバッグするのが難しいのに対し、優れたプログラマーは、エレガントで修正が簡単でほとんど壊れないコード行をいくつか作成するためです。時間がかかりますが、全体としてはより良い選択です。
- 生成されたバグおよび/または修正する時間-誰もがいくつかのバグを生成します。多くの場合、最も高価なバグは、問題の生成者がドミノ効果の最後にすぎない一連の悪い決定によって生成されます。また、優れたデバッガーが優れたデザイナーであるとは限りません。両方が必要です。
- ほとんどすべての指標では、チームに苦労するような素晴らしい開発者がいます。1人の「超生産的」開発者が10人の基本的に優れた開発者を追い払うことになるので、できる人がほとんどいないすべてまあ、私たちはプロジェクトに複数の人が必要になります。
- 特に問題がプロセスのギャップである場合（特に、CMの欠陥、非効率的なビルド、テストのギャップ、セキュリティの欠陥-これらが問題である場合）、深刻になる前に問題が発生することを見込んだすばらしい人々を簡単に説明する方法はありません。災害から救われることに気づくまでは、多くの場合、時間の無駄のように見えます。それを測定する方法はありません。
- また、私が「凝集力ビルダー」と呼ぶ特定のサイズのチームで必要だと考える人々がいます-生産性の絶対的なトップになることはめったになく、彼らは通常まだ上位20％にいて、ランプアップを助けるという非常に貴重な仕事をしています新しい人々は、点をつなぎ、適切な質問が行われ、適切な人々がループに留まることを確認して、彼らが正しいドキュメントだけでなく、誰もが参照する重要なドキュメントを書きます（手付かずです！）正しい方法で組み立てられています。 10人に最高の効率で仕事をさせたい場合は、これらのスタッフの1人が絶対に必要です。10人のスーパー開発者を部屋に入れても、それは得られません。
多くの測定システムはこれらの要因を考慮に入れようとしましたが、これらの問題のすべてを考慮に入れるものがあることをまだ確認していません。したがって、「優れた開発者は、というのは、このメトリックは、成功している継続的な製品または成功しているチームに投入するために必要なすべての作業を実際に説明しているのかどうか疑問に思っているからです。
だから私の大きな警告は-このメトリックで何をするつもりですか？このようなものを使用して、適切なツールと才能が作業の方法に大きな違いをもたらす可能性があることを認識しますが、各個人が「標準的な」出力を10倍生成するチームに最適化しようとすると、欲求不満のケース。より良い連携により、チームが以前と比べて2倍から3倍にできる方法を見つけることがより良いです。
彼の著書 ソフトウェアエンジニアリングのレプラコーン で、ローランボサビットは10倍の生産性の主張の研究について説明しています。彼はその背後に健全な数字がないことを発見しました-主張は推測から「確固たる事実」へと続きました電話ゲームより具体的な主張の連続引用。 10xクレームの章を構成し、関連する引用と誤記を含むブログ投稿は ソフトウェアエンジニアリングにおける事実と民間伝承 です。
彼が見つけたのは次のようなものです。1968年に誰かが特定のデバッグ問題を解決している人々を比較する調査を行い、一部の人は他の人よりも10倍速くそれをしたことがわかりました。これから、一部の人々は10倍その問題の解決に優れていると結論付けることができます、または一部の人々は結論を下すことができます幸運、または多種多様なものを得ました。一部の人々はこれを引用しました（これらはすべて言い換えです）。「ある研究（Sackman et al、1968）は、一部のプログラマーが他のプログラマーよりも10倍速く動作することを発見した」その後、「優れたプログラマーは平均よりも10倍優れていることが研究で示されました」、そして最後に「プログラマーの生産性が個人間で10倍異なることは常識です」。次に、誰かがこれらすべての引用を収集し、1つの元のソースを誤って引用して、「多くの研究者が信じている…」と言います。
もちろん、アサーションの真実性のみが変更された場合、それは電話ゲームではありません： 乗数が11以上になる も。
「その環境での生産的なプログラマは、ユーザーのニーズを理解して実装するのが最も得意な人であり、賢いコードを書くことができる人ではありません。 "（From Carson630 回答）
その重要なポイントと bethlakshmi のポイントを組み合わせると、大きなポイントになります。優れた開発者は、現実の彼/彼女の1つのスライスで素晴らしいかもしれませんが、世界が変わるとすぐにバラバラになります。ビジネスのニーズに対応できることは、何よりもはるかに重要です。結局のところ、あなたのビジネスがテクノロジーでない限り、ビジネスはテクノロジーを気にしません。彼らは解決策を必要としています。したがって、デザインパターンが優れているからといって、ウェブページに表示するためにデータダンプが必要なだけのエンドユーザーにしゃがむ必要はありません。優秀な開発者が飽きることなく終わりのない挑戦を求めて立ち去る一方で、平凡な開発者が彼らをサポートするビジネスにケータリングすることによって彼ら自身の仕事を確保するのを見てきました。組織やプロジェクトによっては、これらの課題の多い開発者を養うことは可能ですが、その量の処理能力を必要としない場合もあるでしょう。これらの開発者は、プロセッサのように単にアイドル状態でいることを好みません。それらは他の場所でシャットダウンして再起動します。
最後に、あなたの「主要な」パフォーマーが誰であるかを知ることは問題ないと言いますが、開発「チーム」はまだチームです。 bethlakshmiを繰り返しますが、「このメトリックで何をしますか？」チームのように動作するチームが必要な場合、私は焦点を当てませんこれらのメトリックについて。最小のプレーヤーでもチームの重要な部分であることに気づきます。キープレーヤーの生産性が60％低くても、その1人のプレーヤーがチームに必要なものを提供している可能性があります。それが何であるかを見つけて、それを乗算してみてください。キープレーヤーがチームを率いると想定して、他のプレーヤーをその偉大さで汚染することにより、彼の出力を増やす方法を見つけることで、キープレーヤーを燃やさないでください。これには、数値だけでなく、少し創造性が必要です。結局のところ、優れたプログラマーを作るものはそのプログラマーでさえないことを学ぶかもしれません。それは彼の同僚、職場での彼の機会、あるいはあなたかもしれません。