最近なんとなーく考えることをまとめてみる。
まず開発における「QT曲線」というのを提案したい。Qとは成果物(プログラムのことね)のQuority(品質)のこと。Tは成果物を作るためにかかるTime(時間)のこと。クオリティが高いプログラムは，バグが少なかったり，パフォーマンスが高かったり，落ちなかったりする。時間をかければ，クオリティが高いプログラムを作ることができる。
実装にかける時間とともにクオリティは上昇するけど，一般的には線形にクオリティが上昇するのは一定時間までで，それ以上は上昇のカーブはゆるやかになる。
時間をかければ成果物のクオリティは上がる。が，開発に掛けられる時間は限られている。なので，掛けられる時間によってクオリティが制限されたり，逆に求めるクオリティに応じて開発にかける時間を見積もったりする。
一般的な開発では，問題はもっと複雑になる。たとえば，成果物についてどの程度のクオリティを満たせばいいかが，たいていの場合明確でない。開発者なり設計者なりが自ら，システムの性質や利用のされ方をよく理解した上で，クオリティのターゲットを設定する必要がある。
また，一つの要件を実現するために，たいていは複数の手法がある。手法によっては，手早く実装できるけどクオリティが高くなかったり，対応に時間が掛かるけど成果物のクオリティが高かったり。なので，現場では，複数ある開発手法のうち，引き出しから適切なものを選んで，実戦投入することになる。
たとえば。１回しか実行しないような特殊なテキスト処理を実装するために，時間をかけてクオリティの高い成果物を作るのは明らかにオーバースペックである。１回しか使わないのだから，多少融通がきかなかったり，多少遅くても手早く作れるような手法を使う方が好ましい。
一方，サーバ上で稼働して，いたるところから繰り返し呼ばれるようなロジックは，時間をかけてクオリティの高い成果物を作るべきだ。そういうロジックが遅かったら，ボトルネックになってシステム全体のパフォーマンスに影響を与える。
こういう風に，「どのような条件で何を作るか」に依存して，掛ける時間とクオリティのスウィートスポットが存在するわけである。
デキる開発者は，見積もりが適切で，見積もりにあった適切なクオリティを実現するための「手法の引き出し」をたくさん持っている。必要とされる最小限度の道筋で成果物を作れるので，仕事が早いし，仕事が早いからと言ってクオリティが低いわけでもない。
つまり，優秀な開発者は，開発のスウィートスポットをつかむのがうまい。
逆にデキない開発者というのは見積もりがあまりうまくなかったり，手法の引き出しが多くなかったりして，開発に無駄に時間をかけてしまったり，本来求められるクオリティを満たせなかったりする場合が多いような気がする。
