プログラマの特徴（用語）
「バグ（ＢＵＧ）」という言葉がある。
プログラマ以外の方は、意味もわからず使っている人もいるがプログラマを自称する人でも、正確な意味を意識していない人もいる。
コンピュータシステムが真空管を使っていた大昔に、コンピュータルームに入り込んだ虫（ＢＵＧ）が原因でシステムが停止したのことが、「バグ」の語源である。そこから、プログラムに入り込んだ、プログラマが意図していないミスのことを、バグと呼ぶようになった。プログラマが書き上げたプログラムを検査する「デバッグ」という作業は、バグを除去するという意味だ。
この定義でいくと、プログラマが意図したミスか、意図していないミスかが問題となる。意図したミスというのは、とてもおかしな表現であるが、こちらはバグではなく「設計ミス」あるいは「仕様」と呼ばれる。仕様がおかしいためにプログラムが期待通りに動作しなければ、「バグを修正」するのではなく、「仕様変更・修正」することになる。
設計ミス、仕様については、プログラマにも責任があることはあるが、会社上部あるいはチーム、コミュニティ全体の責任による部分である。某コンピュータソフトメーカーは、（傍目から見たら）明らかなバグを、仕様という言葉で強引にねじ伏せる・・・それって開き直りか？
バグには色々な種類がある。時限爆弾のように、ある年月日になるとシステムが異常となるものや、コンピュータの資源（ＣＰＵ時間、メモリ、ハードディスク容量）を徐々に食いつぶすものや、自己増殖を繰り返すものなと様々だ。これらの例をみると、コンピュータウィルスのようでもあり、ぞっとする。
バグの数には、数学的な理論がある。あるプログラムに１つバグがあったとすると、それ以外に後２つはバグが潜在している可能性が高い。つまり、数回デバッグを繰り返すと、バグの数は級数的に増加し、それらすべてを除去することは不可能に近くなる。
また、バグの数とプログラムの規模は正の相関があり、プログラム規模が増大するとバグの比率は徐々に高まる。これらの理論から、言えることは・・・
「良質のものをコンパクトに作りなさい」ということである。
プログラマの理論
