プログラム界の法則を語る

プログラム界の知られている法則について、３人で語り合いました。

今日は、プログラム界の法則について話し合おうかと。

よろしくお願いします。

まず最初は「ブルックスの法則：遅れているプロジェクトに人員を投入しても、さらに遅らせるだけである」。

これは有名ですね。大学生の頃から知ってました。

それは早いね。私は会社入ってから知りました。

この法則は1970年代に提唱されているんだけど、未だに現場で見かけるよね。遅れているプロジェクトに中国人プログラマーを増員した、とか。

それ、典型的にダメなやつじゃないですか。

そもそも会社で「人月」という単語が普通に使われていたのが意外でしたね。「人月の神話」読んでないのか、となるわけで。

人月とウォーターフォールは、管理する側からは楽なんだよね。

ちょうど今、テスト駆動開発について勉強しているのですが、このやり方はソフトウェアの品質向上には効果がありますが、完成時期とかを見積もるのは確かに難しいですね。

ある程度の見積もりがないと、組織として動けないからね。

ウォーターフォールの原著について知ったのですが、原著の段階では工程が後ろに戻ることも考えられていたんですよね。

へぇ、そうなんですね。

ところが名前が悪かったのか、後ろに戻らないモデルとして知られてしまっているんですよね。

次も有名な「ムーアの法則：半導体の集積率は約２年で倍になる」。

この法則は終わりが見えてきてますけどね。

物理的な限界が来ているみたいだね。 それとは別に、モバイル機器の普及で、省電力化にもマンパワーを割いているという側面もあるみたいだけど。

物理的に限界だから省電力化に力を入れてる、という話なのかと。他に、ターボブーストなどの技術向上があったのも、同じような事情だと思いますね。

そんな感じですね。

一方、GPUのグラフィカル能力というのは、ハード的にもソフト的にも、近年まだまだすごい向上があったんですよ。この分野はまだムーアの法則の限界は来てないですね。

続いて、「ヴィルトの法則：ソフトウェアは、ハードウェアが高速化するより急速に低速化する」。

これは初耳です。ソフトウェアがどんどん大きくなっていく、ということですか？

そうそう。OSの起動時間とかプロセスの起動時間とかが、ハードウェアの進化ほども速くなってないのは、ソフトが肥大化してるから、ということ。

ソフトウェアの抽象化とかが入ると、アセンブリレベルとは規模が違ってきますからねぇ。

続いて「ダイクストラの箴言：プログラムテストは、バグが存在することを証明するには有用だが、バグが存在しないことを示すには絶望的に不適切である」。

悪魔の証明ですもんね。

さっき言ったテスト駆動開発の本では、テスト駆動開発はあくまで設計のための手法である、と強調されてました。万全のテストを書くというのは事実上不可能なのでしょうね。 個人的には、ソフトウェアでできてしまうことを減らすことが、バグを減らすの良い方策と考えています。

確かに。マーフィーの法則じゃないけど、最悪のことって起こってしまうんですよね。なので、動作から抑え込んでしまうのは有効だと思います。

ところで、グラフィック系のテストってどうやるんですか？

便利なデバッグツールとかはありますけど、リグレッションテストとなると難しいですね。やはり最後は目視が必要となるので。

さらにソフトウェアの法則じゃないけど「ハインリッヒの法則：1つの重大事故の背後には29の軽微な事故があり、その背景には300の異常が存在する」。 1つバグが見つかったら他に29個はあると思った方が良い、ということだね。

車の運転をしてて思うのは、小さなことが複数重なって重大事故になるんじゃないかな、と。なので、実質無害そうなバグでも、修正していくことに意味はあると思いますね。

グーグルのテスターだった人が書いた本を読んだのですが、テスターの人は設計段階から関わるらしく、テストで潰せる所は潰してしまう、という思想が感じられました。