虫のあるものと虫のあるものを結合すると、虫のあるものになる。
　虫のないものと虫のあるものを結合すると、虫のあるものになる。
　虫のないものと虫のないものを結合すると、やはり虫のあるものになる。

【否定則不成立の法則】

　プログラマの熱い期待にもかかわらず、二度間違えると正しいプログラムになる、ということはない。

　世の中のすべてが自分を中心に回っているように感じられたら、早く家へ帰って休養した方がよい。ジェットコースターの乗り過ぎである。

【強度の心身症の診断法】

　すべての人の視線が自分に集中し、自分の一挙手一投足が監視されているように感じられたら、これは大変まずい状況にある。従業員バッジを付けたまま電車に乗っている可能性が強い。

【極めて危険な状態の心身症の診断法】

　すべての物が自分に向かって突進し攻撃してくるように感じられたら、これは極めて危険な状態である。自分の車が反対車線を走行している可能性が強い。

　マニュアルの厚さは、そのソフトウェアのパッケージが値段に見合うボリュームになるまで増大する。

【ファイルサイズの法則】（上記法則の改訂版）

　ソフトウェアのヘルプファイルの大きさは、そのソフトウェアの値段に見合うボリュームになるまで増大する。

【マニュアルの分かり易さ】

　マニュアルの文章は、既にその使い方を知っている人にしか理解できないような言い回しで記述されている。

【マニュアル批判の公理】

　マニュアルに対するいかなる批判も、必ず正当化される。

１．プログラムが思い通りに動かなければ、机上デバッグを行う。
２．机上デバッグでうまくいかなければ、マシンデバッグを行う。
３．マシンデバッグをしてもうまくいかなければ、人のせいにする。
４．責任をなすり付ける相手がいなければ、マシンのせいにする。

【最近のプログラマの追及の手順】

１．プログラムが思い通りに動かなければ、マシンデバッグを行う。
２．マシンデバッグがうまくいかなければ、人のせいにする。
３．責任をなすり付ける相手がいなければ、ところ構わずキレル。

　プログラマは中年になるとゆったりとした服を着たくなる（これは好みの問題だから特に問題ないのだが）。問題は、身体の方が服に合わせて変化してしまう点である。

【スタイル重視の原則】

　若いプログラマは、プログラミングスタイルに気を配らねばならない。
　中年のプログラマは、ボディースタイルに気を配らねばならない。

　不足は増大する。

【虫の発見件数と開発費の関係】

　増大は減少し、それに伴い減少は増大する。

　どんなコードも最初は正しく見える。

【デバッグの法則への修正】

　最初から殺人者のように見える犯人はいない。しかし最初から虫のように見えるコードは存在する。

　プログラムの虫には、コードの中に存在する虫と存在しない虫（コードの欠落）とがある。プログラマにとっての最大の不幸は、コードの中に存在しない虫に対してもコードの中を捜し回らねばならぬ点にある。

　プログラマは、常に次の２種に類別される。
　・プログラミングはできるが、管理は苦手である。
　・プログラミングは苦手であるが、管理も苦手である。

【プログラマ初体験の法則】

　プログラマは、
　・初めて作ったプログラムが正常に動作したときの感激を決して忘れない。
　・最初に虫を作り込んだプログラムのことは決して思い出せない。
　・両者が同一のプログラムであるという事実には決して思い至らない。

　ジョークが分かる人は、ここで【再帰的呼出しの法則】を参照する。
　ジョークが分からない人は、ここで【空 手続きの法則】を参照する。

【空 手続きの法則】

　む‥‥。　//* だれもジョークが分からない！

　取扱説明書（取説）における「巧みな表現」とは、将来言い逃れができる余地を残した表現方法をとることである。

【理解と誤解の法則】

　ソフトウェア説明書の文章は、決して作成者の意図通りには理解されない。必ず、恐れていた通りに誤解される。

【誤解の法則】

　誤解を恐れずに書くと、その通りに誤解される。

　特許提案における「巧みな表現」とは、将来幾らでも拡大解釈が可能となるような表現をとることである。

【適用範囲の法則】

　取扱説明書を書くときには、できるだけ適用範囲が限定されるように書く。
　特許申請書を書くときには、できるだけ適用範囲が拡大されるように書く。

【手遅れの法則】

　たまに良いアイディアを思い付くと、既に提案されしかも検討の結果却下されたものと同じである。
　たまに採用されるアイディアは、既に他社から特許出願されているものと同じである。

　社内では特許は数で勝負する。社外では、特許は質で勝負する。

【よい表現とは】

　最悪の事態に備えて、特許提案の文章には必ず「原則として」という言葉を添えておく。

【よい機能とは】

　簡単に作ってしまった機能にはすぐ苦情が来る。
　苦労して作った機能に対しては苦情は絶対に来ない（誰も使わないから）。

　プログラミングの世界では、行列が二つあったら短い列の方に並ぶ。
　実生活では、行列が二つあったら取り敢えず長い列の方に並んでおいて、それから何の行列であるかを確かめる。

　表示されているメニュー項目の機能に過大な期待を持ってはならない。
　メニュー通りのうまい料理が出てきた試しはない。

【ホットキーの法則】

　メニューを見ないで注文しようとすると、ホットキー(*)の名前が思い出せない。メニューを開いて思い出したときには‥‥　もはや使う必要がなくなっている。

　注(*) ホットケーキではない。ホットキー（簡略キー）のことである。

　トラブル対策の責任を持つ人は、虫を修正する技術を持たない。
　虫を修正する技術を持っている人は、トラブル対策の責任を持たない。

【労力の原理】

　虫を潰す労力より、謝る労力の方がずっと楽である

【謝罪の法則】

　謝りに行く人は、事態の深刻さを正確には把握していない人の方がよい。

　翻訳書を読んでいて意味が分からなければ、それは翻訳者も意味が分かっていない証拠である。そんな本はさっさと捨てて原著を買って読んだ方がよい。

　　注(*) あえて誤訳とは言わない。

　変更可能なものは、永遠に変更され続ける。
　変更不可能なものも、時間が許す限り変更され続ける。

【設計変更に関する評価の法則】

　設計変更というものは、いつも最初は「たいした影響はない」ように見える。

【要求仕様のはかなさ】

　正式版は、テスト版の通りには動かない。
　テスト版は、要求仕様の通りには動かない。
　故に、要求仕様と正式版とは何の関わりもない。

　プログラムを複雑にするのは簡単で手間は掛からない。しかしプログラムを簡単にするには複雑な手間が掛かる。

【シュリンクの法則】

　洗練されたプログラムと洗ったシャツは縮む。

【拡大と縮小の法則】

　シャツは洗うたびに小さくなるが、プログラムは改造するたびに大きくなる。

　コンパイラがエラーメッセージが山ほど表示したとしても、最初のエラーにだけ対応すれば十分である。残りはすべてコンパイラの勘違いだから。

【本物のプログラムとは】

　コンパイラのエラーメッセージが出る内はまだプログラムではない。エラーメッセージが出なくなったら、いよいよ虫のある本物のプログラムになったといえる。

　品質が話題になり始めると、それはもはや開発費が底をついたことを意味している。

　利用者からの反応がないので安心していると、実は誰も使っていない。
　ときたま反応があると、それはトラブルの報告である。

　品質管理者にとって：
　「縁起」とは担ぐものではなく、
　　　かつがれて精神の安定を得るためのものである。
　「迷信」とは信じるものではなく、
　　　信じるための拠り所とするためのものである。
　「奇跡」とは起こすものではなく、
　　　起きることを開発部門の人に信じ込ませるためのものである。

　「数値目標」とは、品質管理部門が開発部門に求める品質に関する最高級難度の要求値のことである。

　優秀な管理者は、
　　予期せぬ事態に備えてスケジュールに余裕を持たせる。
　取り分け優秀な管理者は、
　　予期せぬ事態の予期せぬ遅れに備えてスケジュールに
　　更に余裕を持たせる。

　コンピュータのプログラムなどというものは信頼できない。
　それを作ったプログラマは尚更信頼できない。

　人間の信頼性に重きを置くプログラムを、人は信頼してはならない。

　最新のマシンを持っている人は、それを自慢できる。
　一世代前のマシンを持っている人は、
　　　それを使うことにまあ我慢ができる。
　二世代前のマシンを持っている人は、
　　　それを使うことに何とか耐えられる。
　三世代前のマシンを持っている人は、
　　　それを使うことに耐えられない。
　四世代前のマシンを持っている人は、
　　　それを使っていることをもはや公言できない。
　五世代前のマシンを持っている人は、
　　　持っていることを自慢できる。

　マシンを購入して、早まったと後悔しないための方法：
　１．金持ちになって次々とマシンを買い換えられる身分になる。
　２．マシンの購入を永久に先延ばしする。

　ソフトウェアとは、
　　組み立てるのも分解するのも同じ様に簡単でないものを言う。

　ウィンドウは換気が悪いので、ときどき開放（解放）して空気を入れ換える必要がある。

　プロジェクトは、
　　プロジェクト室を獲得することによってその重要度を認知される。

　プロジェクトリーダーとは、
　　プログラム作りから最も遠ざかっているメンバーのことである。

　プロジェクトに与えられる開発期間は限られているとしても、プログラムを修正する期間は無限にある。

　人間は、二度と使う可能性のないファイルでさえも取り敢えずハードディスク上に保存することによって心の安定を得る。

　ファイルは、永く保存しておけばおくほど熟成されて捨て難くなる。それを捨てる決断がつくのはハードディスクが満杯になったときだけである。

　ファイル破壊の事故は、常に「ファイルを保存したい」と熱烈に思う直前に発生する。

　自分のマシンは、他人のマシンよりみすぼらしく見える。

　新しいマシンを購入すると、翌週には友人がもっと掘り出し物のマシンを購入している。

　私用のマシンは、古くなればなるほど愛着が増していく。
　社用のマシンは、古くなれば直ぐ愛想が尽きる。

　故障したマシンは、保守員が来る直前に一時的に正常動作するようになる。
　買い替えのための申請書を提出すると、まったく正常なマシンになってしまう。

　簡単に直るトラブルの発生源は自分の担当モジュールではない。
　たちの悪い致命的なトラブルの発生源は、どういう訳か必ず自分の担当モジュールである（経験者は【不運不運の法則】と呼びたくなる）。

　プログラマの熱い期待にもかかわらず、プログラムの欠陥（虫）が自然に直ることはない。