Joel on Software - give IT a try

Joel on Softwareを読み終えました。
なかなか面白かったです。
印象に残った項目を挙げてみます(数字は章番号です)。

退屈な仕様書は読んでもらえないので、ちょっとふざけた感じのユースケースシナリオにした方が良いとの意見です。
実際にできるかどうかはさておき、確かにそういう仕様書もいいかもしれません。

Googleがそれを実践したと言われて納得。
単純に日付順とかID順でソートしがちですが、意識を改める必要があるかもしれません。

これは非常に同感。
おいらも1つのことに集中したい〜！！

どんなに汚いコードでもバグ修正されてちゃんと動いているからだそうです。
フルスクラッチで書き直すのではなく、少しずつリファクタリングしろと書いてあります。
確かにそうかもしれませんが、致命的なバグをいっぱい抱えたままのプログラムを見つけた場合は例外としても良いでしょうか？先生・・・。

あまり実感はありませんが、ありえる話かも。
今後はちょっと気をつけてみます。

分かっていてもついつい後回しになってしまいがちですね・・・。
Apple製品が好きなら自分が作るシステムの見た目にもこだわるべきなんでしょうけど。。。

たとえばASP.NETの生産性は高いが、HTMLやHTTPの知識を完全に不要にする訳ではない、といった感じです。
確かにそうですね。どれだけ新しい技術が出てきても基礎的な勉強は不可欠です。

これはまさしくそうかも(これまでの自分を振り返って・・・)。
公平で客観的な評価って難しいですね。

コードを書き直す誘惑にとらわれるな、とのことです。
5年ぐらい前に作られたシステムがありますが、未だにバグだらけなのでできることなら今からでもバグ修正させたい。。。(エラー発生件数は1日あたり平均約30件!!)

だからMicrosoftはここまで大きくなれた、と。
今まで当たり前だと思ってきましたが、パッケージ製品を作る側からすると後方互換性の維持っていうのは無くしてしまいたい面倒な仕様なんですね。