blog.fuktommy.com

> 最初は機能が少なくてもパフォーマンスが速いこととバグがないことだけは守るべきだ

その通り。

> ユーザーが欲しているとイメージしたものは必ずと言っていいほど間違っているわけです。
> (中略)間違っていることに気づいて、それをすぐに改善できる開発のスピードが大事

うんうん。まったくその通り。でもそれがなんで

> コードがどれくらいきれいかを気にする人は出来の悪いプログラマー

になるんだろうね。これは矛盾していると思うんだが。
というのも、汚いコードはたいがい設計が腐ってる。
したがってバグがあるのは当たり前だし、パフォーマンスも悪い。
それでもいいから開発速度を優先するというのもありえなくはないが、
アイデア一発勝負みたいな、ごく限定された状況だけだと思いますよ。

そして汚いプログラムを直したり新機能を入れたりするのにはやたら時間がかかる。
それでいいというのは、最初のサービスインは急ぐけど、
それ以降の改善はゆっくりでいいという、これまた不思議な状況で、普通には考えられません。

http://wired.jp/2012/02/03/interview-ginzamarkets/5/

んで

> ポイントは、「コードの見た目は後でいい。」の部分で、
> おいらは、コードの見た目はいつまでも汚いままでいいとは言ってなくて、
> 直す必要があれば、後から直せばいいと書いてるわけです。

後から直す時間なんかありませんよ。
ユーザーの動向をみて、どんどん新機能を追加するなり、使われてない機能を削るなり、
新規の開発をやらねばならんのです。