＃2：Windowsの設計は数々の妥協の上に成り立っている
私が耳にしてきた数多くの不満を煎じ詰めると「うーん、私だったらそのような機能設計にはしなかっただろう」というものになる。確かにそうかもしれない。しかし、多くの人々が使用する製品を開発する際には、何らかの最大公約数を導き出さなければならないのだ。そして2008年2月の投稿（英文）でも書いたように、正しい答えが存在しない場合もしばしばある。あなたが行う意志決定は、それがどのようなものであったとしても、それなりの数の人々によって嘲笑されることになるのだ。
また、Microsoftは機能の削除を絶対に行うべきではなく、昔からのユーザーが5年前や10年前、あるいは20年前に学んだ操作方法を使えるようにしておくべきだというフィードバックも、私は数多く耳にしている。実際に私は、Windows 3.1に搭載されていた旧式のファイルマネージャをWindows 7にも含めるべきだと主張している人に出くわしたことがある。いっさいの機能を削除せず、1991年以来の1ダースほどにもなる古臭いインターフェースから選択できるようにすることで、Windowsのコードがどれだけ複雑になり、肥大化するか想像できるだろうか？しかし、これこそが先の主張から導き出される論理的な帰結なのだ。
ものごとは進化していくのだ。古い機能は消え去り、新しい機能がそれに取って代わっていく。この流れを受け入れなければならない。新しい機能を実装するにあたり、Microsoftが選択した方法よりも優れた方法があると思うのであれば、それをブログに投稿して欲しい。ただし理性的な投稿を心がけて欲しい。読ませたい相手はエンジニアであるということを忘れてはいけないのだ。単に「XYZという機能は使いものにならない」と書くだけでは、彼らの心を捉えることなどできないだろう。
＃3：優れたバグレポートを記述することは難しい
バグレポートが「再現不能」として対応完了扱いにされたと嘆いているテスターには同情する。しかしそれが現実なのだ。そのバグが容易に再現できるのであれば、Windowsをビルドするたびに実行される数多くの自動化されたテストサイクルのいずれかで捕捉されていたはずである。本当にややこしいバグは、あまり一般的でないハードウェアとソフトウェアの組み合わせで、特殊な条件が満足された時に引き起こされるのだ。
実際のところ、テクニカルベータテスターから送られてくるバグレポートの調査を行うデベロッパーと話をすれば、私が感じたように、こういった作業の実りの薄さを実感できるはずだ。ほとんどの内容は重複しており、大部分は単に新機能のリクエストであったり、既存機能の変更リクエストになっているのだ。それが「対応せず」や「仕様である」として対応完了扱いになったということは、そういったリクエストについては過去に検討済みであり、現在の状態が最適であると判断されるだけの数多くの理由（予算や互換性、機能低下のリスク、データの矛盾）があるということなのだ。
