どんなに注意して仕事をしているつもりでも、人間のやることに完璧ということはない。開発中に見つからなかった不具合（潜在バグ）が、リリース後に顕在化して、大問題になるようなこともよくある。
システムが大きくなり、複雑になるほど、そういった危険性は高くなる。仕様の全てを人間が把握しきれなくなり、「盲点」、「死角」が増えてくるからだ。
特に、何度も改訂を繰り返したようなシステムは、不自然な建て増し建築のように、見通しが悪くなることが多い。どこかに手を加えれば、とんでもないところに不具合が出てくる、といった状況になりやすい。
人間が「気がつかないことに気がつくこと」は非常に難しい（というか、言葉の上では矛盾しているのだが・・・）。「バグのないプログラムはない」と言われる所以だろう。システムの品質の確保は、最終的にはこの問題をどうするか、ということになるのではないだろうか。
ひとつには、開発者の視点とは違う角度でチェックを行うことである。例えば、設計書などを第三者にレビューしてもらったり、モンキーテスト（厳密に計画しないテスト。出鱈目な操作をするなど）を行ったり、といったことだ。いわゆる「β版」を配って、多くのユーザーに試用してもらうのも、同様の意味があるだろう。
もっと本質的な解決方法は、なるべくシンプルな設計をすることで、死角が生じないようにすることだ。そのためには、顧客の業務・運用をシステムに合わせて変更してもらった方がよい場合もあるかもしれない。また、システムが改訂によって複雑化しそうなら、全面的に作り直すことも提案すべきだろう。
そのあたりは、開発を依頼する側にも、理解してもらいたいところでもある。実際、目先の費用をケチったために、会社の信頼に関わるような致命的な不具合が生まれたり、以後の改訂費用が増大したりするケースも少なくないのだから。