最近僕も似たようなことを考えていたので、これを機にちょっと文字にしてみます。実際のところ10倍とか100倍とかっていう開きもあり得るんじゃないの?という話です。ちなみにmizchiさんはこのマイナスの生産性を「技術的負債」と表現しています。「週にrの成果を出し、dだけソースを汚くする」ようなエンジニアの生産性を求めてみます。以下のように定めます。p:生産性r:ソースが理想的に綺麗な状態において、1週間に出せる成果の量d:1週間に出してしまう技術的負債の量c:技術的負債が生産性に与える影響を表す係数x:経過日数(単位:週)すると、単位週あたりの生産性は以下のような式で表せます。dx/100と表せるとします。「もはや誰にもメンテ不可能なゲロ以下のコード」ということです。dx/100)ということになり、1週間に出せるMAX成果量と出してしまう負債量を与えれば、そのエンジニアの生産性が、経過日数によってどのように変化するかがわかるようになります。何人かのパターンのエンジニアを上記の式に当てはめて試してみます。プロジェクト開始時は10だった生産性が、2ヶ月半ほどで7に下がります。2.週に15の成果を出して10の負債を生む人こんな感じ。なんと2ヵ月半後には生産性が0です。当たり前ですが平らです。プロジェクトの開始から最後まで一定の成果を出し続けます。これを積分すればプロジェクトを通しての生産量も求められますが、ここではそういうことをしたいわけではないのと、そもそもcを表す式やr,dの値の妥当性がかなり怪しいので、そういうのはしません。汚いソースを書くエンジニアの10倍100倍になることもあり得る」ということです。上記の、10週目には生産性が0になるという例は極端ですが、そうじゃなくても、技術的負債というものがある以上、rやcをもっと妥当な値に変えてみても、やはり長期的な生産性にはかなりの開きがありそう。それに上記の例は、あくまでも「自分が書いたソースを自分で読む」場合の話です。実際には自分が書いたソースを他人が読むケースなんてざらにあり、その場合は負債により減少する生産性はさらに大きくなります(要するにcが小さくなります)。技術的負債を生まないようにすることの重要性はさらに高まるということ。まっさらな状態から「よーいどん」でコーディングを始めれば、おそらく生産性に100倍の開きは出ません。優れた(=綺麗なコードを書ける)エンジニアの生産性は、そうでないエンジニアの生産性を圧倒します。さぁみなさん、綺麗なコードを書きましょう!(結局これが言いたかっただけ)おわり。18:52優れたプログラマの生産性はそうでない奴の10倍とか100倍とかいう都市伝説Tweet広告を非表示にする関連記事2016-02-11【雑記】Parse.comがしんだ「Parseがやられたようだな...」「ククク...奴はmBaaS四天王の中で...2016-01-01エンジニアからコンサルタントにクラスチェンジしてましたしばらく振りに記事を書きます。港区界隈でSEやってた暇人。今はITコンサルとかいう胡散臭い職種になっています。好きな和音はsus4です。(1)月別アーカイブ参加グループプログラミンググループテストしたい人のグループポケモンリンクはてなブログQiitaGitHubはてなブログをはじめよう!sakuramochi702さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。