■ 正しくないかもしれない、間違ってるかもしれない 
デバッグしてるときくらい悲観的になろうぜ。「正しく書いているはずなんだけど…」とは言っても、正しく書かれていないからプログラムがまともに動いていないんだろ？ならば素直に「どこかが間違ってるんだ」って疑っちゃえばいい。で、間違ってる可能性のある箇所を少しずつ減らしていけばいいじゃないか。
ソースコード眺めてたって間違いは見えてこないぞ。そんな文字の羅列を眺めていりゃ見つかるバグを、どうして書いている途中で見つけられないんだ？書いている途中で見つけられないバグは、書いた後でも見つけられないんだ。見つけたかったら、実行してみないと。
追記：ソースコードを読んでバグを見つけられる人たちの思考回路が理解できない。頭の中で一体何をやっているのだろうか…と問いただしたくなる。例えば変数を3つ使って行う作業を頭の中で行おうとしたら、最低でも3つのことを同時に、しかも正確に覚えていなければならない。そんなことができる人間がこの世に何人いるのだろうか…
バグが出たときに再現性も確かめず、何が起こっているのかもちゃんと把握できていない状態でいきなりソースを眺めはじめる人もたまに見かけるけれど、バグを取るいちばん確実で簡単な方法は「100%再現するやり方を見つけてからデバッガで追う」ことだろう。大抵の場合は100%再現できた時点で原因もほぼ特定できる。そうするためにも、例えバグを出してしまうことがあっても再現しにくいバグを仕込まないように日ごろから気をつけておくのがいいのだろう。
それでも、本物のプログラマなら上記のような複雑なプログラムでも頭の中で流れを追えるものなのかもしれない。なるべく富豪的で簡潔なアルゴリズムで書くようにすればバグは減るものの、ややこしい状況を見ることが減るために、複雑なアルゴリズムを考えたり追ったりする能力が退化してしまうようにも感じている。どうしたものか。
■ 体系的なシステム開発 
クリエイティブなゲーム製作とあるけども、もちろんゲーム製作だけがクリエイティブというわけではない。システム設計もアプリケーション開発もそれぞれにクリエイティブだ。
ゲームであれアプリケーション開発であれ、どんな内容のものでも規模が大きくなるにつれ開発手法、管理手法としてなんらかの体系づけられた手法が必要になると言うことだ。
なぜ体系づけられたものが必要になるのか。
体系づけられないと理解できないからだ。
人間、一人が理解し、把握し、制御できる規模というものには限界がある。それぞれについて は個人差があるが無限ではない。私が理解できない規模のものでも別の人なら理解できるだろう。
これが個人差と言うものだ。しかし、それでもいつか理解を越える規模のものが出来上がる。
これが限界と言うものだ。
こうした限界に突き当たる前に、理解が容易な範囲に分割して管理しよう、というのが体系づけられた開発手法、管理手法といえる。
なぜ分割するのか。それは先程書いたように、個人の理解できる規模というのには限界があり、かつ個人差があるからだ。
体系づけられた開発手法というものは、こうした個人差のある理解力でも理解できる範囲に区切って開発対象を分けよう、というもの。どの程度の理解力に合わせるか、というのは開発チームの理解力に左右される。理解力が低い組織による開発であれば細かな単位に分割される、というか分割しないと理解してくれない。理解できない。そうでなければ、大雑把な単位で構わない。
今時のアプリケーションは複雑で、一人で思い付けるものではないし一人ですべてを把握できるものではない。そうした複雑さを克服するために、簡単なものに分解しなければならない。複数人で作業をするのであればなおさらだ。同じ目的を共有するためにも大きな目標をより小さな単純化された目標に置き換えなければならない。複雑なものを複雑なまま処理できる人は限られている。
プログラマの生産性、つまり能力には100倍ほどの差があると言われている。トップクラスのプログラマが100mを10秒で走るスプリンタだとするならば、ひどいプログラマは1,000秒、つまり16分40秒かけて100mを走るのである。普通、徒歩の移動速度が80m/分と言われているので、100mを16分という速度は歩くよりも遅い。できるプログラマとできないプログラマとではこのくらい差がある。
できるプログラマの話を鵜呑みにして、それが自分にもできると思ってそのままマネしようものなら、100mを16分で走るハメになる。
10秒は無理だとしてもせめて15秒、20秒は切りたい。プロだというのなら11秒か。16分もかけて走るような不様な真似はしたくない。そのためにも他人の走り方ではなくて自分に合った走り方というのを考えなければならない。
