My Framework is More Productive than Your Framework(リンク)の中で、Ken DeLong氏 はソフトウェアプロジェクトをさらに生産的にするアプローチについて検証している。フレームワーク、言語およびプロジェクト管理ツールに関する宣伝にもか かわらず、これらはボトルネックにならない傾向にある。Ken氏は、最大の生産性はコミュニケーション、コードの読み取り可能性およびデバッグ可能性が改善される ことにより、もたらされると考えている。
Theory of Constraints(リンク)により、生産性を大幅に向上させる唯一の方法は、ボトルネックに取り組むことだということを知っている。他の分野での収穫は、ボトルネックの制限により占められ、組み込まれる。
Ken氏は、フレームワークはしばしばプロジェクトのセットアップが如何に簡単であるか、また実開発での準備ができているかを売り込んでいることを述べている。確かに、これは便利であるが、プロジェクトのライフを通じて、セットアップ時間は重要でなくなる傾向にある。
生産性にたいした影響を与えない、最適化の別の分野は、コードの記述にかかる時間を削減している。特定の言語、フレームワークまたはプログラミングテク ニックは、記述しなければならないコード量を大幅に削減することができるが、プロジェクトに高い生産性を提供するというわけではない。
この点より「表現力豊かな」プログラミング言語を懐疑的に思う。「表現力豊か」になるには多くの方法がある - 表現力豊かというのは、一般に1つのラインに大量の機能を詰め込むことを意味する。「表現力豊かな」PerlまたはCの読み出しに格闘したことがある人 は、コードの1行にプログラム全部を組み込むのが、いかに素晴らしいのかについて述べたいと思っている。コードの読み出し可能性は、書き込み可能性より重 要であると主張したい。
Stack Overflow(リンク)の最近のポスター(リンク)に、速くタイピングができる人を雇って、生産性を向上したいと出ていた。それを見た人からは、デベロッパの生産性を判断 するのに、タイピングスピードは無関係だという声が上がり、採用時の面接の過程の一部にタイピングテストを使用することにくぎを刺した。Pair Programming Misconceptions(リンク)で、Martin Fowler氏(リンク)はペアプログラミングは生産性を減少するのではなく、向上させると指摘している。その理由の1つとして、タイピングがプログラミングのもっ とも難しい部分ではないからとしている。
デベロッパにとって、ボトルネックの強制力になりそうもない状況を指摘した後で、Ken氏は、ビジネス・ステークホルダーとのコミュニケーション、事前コードの理解およびデバッグなど、ありえそうないくつかの分野について述べている。
Ken氏は、「要求にうまく応えたり、真のビジネス目標を理解したり、また理論的に実行可能な妥協案を見つけることは、確実に多くの時間を必要とする」と 述べている。氏の場合、デベロッパとビジネス間のコミュニケーションを改善するアジャイル開発の側面を導入することで、最大の生産性を実現することができ る。たとえば、製品所有者または現地の顧客を同一場所に配置することで、協働することが多くなり、ビジネス目標や要求の理解につながる。同じように、重量 級の要求スペックをユーザストーリー、会話および受け入れテスト(時々、実行可能な要求と呼ばれる)に置き換えることで、要求の曖昧さや誤解を招く可能性 を少なくする。
自身の環境での、デベロッパにとっての障害の強制力は何か?コメントを残して、共有したい。
原文はこちらです：http://www.infoq.com/news/2009/03/Improve-Bottleneck-Constraints