問題なく動くプログラムができあがった時点でコンピュータ・プログラミングは終わるわけだから、当然、できあがったプログラムには問題がない。非常に理路整然としていて無駄1つない。あるべきものがあるべきところにあるだけだ。できあがったプログラムを見ると、何故これをつくるのにあんなに苦労したのだろう、と不思議にさえ思う。たった独りで行うアマチュアプログラミングというものは、複雑に絡まり合った因果の線の中からシンプルな構造を見つけ出す作業である、と僕は思っている。無駄な線を省き、同じような線を1本に束ね、核を補強する肉づけをして、プログラムという1つの現実のかたちを創り上げていく。プログラミング作業で実際にやっていることは、科学理論づくりのようでもあり、また人間の認知過程の働きそのものでもあるように思う。プログラミングのこんな哲学っぽいところが好きだ。
最近、この「シンプルな構造を見つけ出す」過程において非常に大きな役割を担っているのが実はデバッグである、という事実に気づき驚いている。
プログラミングの途中ですっかりハマッてしまいデバッグばかりやっていると、「プログラミングの90％はデバッギング」というような俗説にグッと説得力を感じてしまう。普通、この説は悪い意味に使われる。つまり、「デバッグというような後向きの作業に大半の時間を費やすのは無駄である」という意味だ。大抵その後には、「キーボードを叩き始める前にプログラムの設計をしっかりしてさえいれば、こんなことにはならなかった。だから、プログラムの設計が大切なのだ」と続く。
しかし、デバッグは本当に「後向きの作業」なのだろうか。何故なら、自分の経験を振り返ってみると、バグ探しをしている過程で試行錯誤的に実に多くのことを学んできたと思うからだ。大袈裟な表現ではなくカンジンなことは全てデバッグ中に気がついたとさえ言ってよいのではないか。もちろん、原因不明のエラーに悩まされていてわけがわからずゴチャゴチャやっているうちにエラーメッセージが出なくなった、というのではダメだ。バグ探しというのは、まさに、事実の収集、仮説の導出、仮説の検証、また事実の収集……のサイクルで、エラーの原因を突きとめるということは、単に不具合が1つ減ったということではなくて、プログラミング言語・プログラム開発環境・OSに対するプログラマーの理解度・習熟度（ドラクエなどのRPGで言うところの経験値）が1つ上がったということを意味している。自分の犯しやすいミスを知るという意味で、自分探しにもなる。
ソフトウェア会社の経営者なら「1つのバグを見つけることに時間をかけるくらいなら、新しいコードを書け」と言って当然かもしれないが、プロのプログラマではなくて見よう見真似のアマチュアプログラマにとって、新しいコードを書くことよりも1つのバグをしっかり解明することの方がよほど大事だと思う。そういった意味で、デバッグを楽しめるかどうかがプログラミングの向き不向きを決めるかもしれない。
というわけで、確かにプログラミング全作業時間の90％はデバッグに費やしてしまったかもしれないが、得たものの90％はそのデバッグを通して身につけた、とも思うわけだ。
