いきなりですが超高層ビルを建てるとします。
設計に問題があれば、どんなに施工が完璧でもビル崩壊の可能性が残ります。
また設計が完璧でも、施工に問題があればやはりビル崩壊の可能性が残ります。
さらに設計も施工も完璧でも、設計時の想定外のことがおきれば・・・
つまりどんなに頑張ってビルを建てても、ビルは崩壊する可能性がある！ということを言いたいわけではありません(笑)
これをプログラミングに置き換えてみます。
☆アルゴリズムに問題があれば、どんなにコーディングが完璧でも不具合の可能性が残ります。
またアルゴリズムが完璧でも、コーディングに問題があればやはり不具合の可能性が残ります。
さらにアルゴリズムやコーディングが完璧でも、想定外の状況になれば・・・
つまりどんなに頑張ってプログラミングしても、不具合は起きる可能性がある！ということを言いたいのです(笑)
なので不具合が発生したとき、個人でプログラムを組まれている方は自分の問題であることは明白ですが、チームを組んで制作している場合、一般には業務で開発している場合に不具合が発生したとき、まず自分が原因ではないかと疑ってほしいものです。では何を疑えばいいのか？
上記☆をみるとなにから見直せばいいのか大変そうですが、不具合の多くの原因は想定外の状況になったときです。何故かというと、想定している状況下で設計どおりの挙動をすることは事前に検証しているはずだからです。検証していないのは論外ですし、そのレベルでのデバッグ、設計やコーディングに関しては、経験や努力で向上しますし、参考文献も広く出回ってますのでここでは割愛します。
ゲーム業界では、左右同時押しによる不具合が有名でしょうか。左右同時って押せないじゃん！と突っ込みたくなりますが、コントローラの不具合や改造などでそういう信号が送られることは起こりえます。
このようなことを無限に想定することは不可能ですが、常日頃から「こんなことがあったら～」のような事を考え（それがとてつもなくくだらない事だったとしても）物事に関する切り口の引出しを広げる。そのことにより想定の幅を広げることができ、結果として不具合が少なくなる、もしくは不具合が起きてもすぐに状況を把握して対応できるようになるのではないでしょうか？