この話は、最近LinkedInのMulticsフォーラムに投稿したメッセージを編集したものです。
自分の変更点を非常に早く「公開」させることは、強力なインセンティブになります。 これは、1960年代後半から1970年代初頭にかけてMITで作られていた主要なオペレーティングシステムであるMulticsに最初に導入したバグについての話です。
私はMITの若い新入生で、Multicsプロジェクトに参加していました。私は、ラインプリンタデーモンが処理するためのリクエストをキューに入れるdprint("daemon print")コマンドに機能を追加することを志願しました。管理者の一人から、キューにN個のリクエストを追加するのではなく、リクエストに含まれるコピー数を記録するように頼まれました。この変更は、完了した印刷要求の削除を含む競合状態を解決します。私はこの変更を行い、満足いくまでテストしました。
私の変更はすぐにインストールされ、私はシステムを改善することが許されることにワクワクしていました。しかし、私はすぐにオフィスの電話に出て、私が自分のプログラムを壊してしまったと文句を言っている憤慨しているユーザの声を聞いていたので、私のワクワク感は短命でした。私は戻って、同じソースファイルへのサブルーチンのエントリポイントに気づいていなかったり、テストしていなかったりしたことを確認しました。案の定、私はそれを壊していました。私はそれを修正し、人生は続いた。しかし、私はあの電話のことを忘れたことはありません。私はまだ完璧ではありませんが、頭の中で響くその怒りの声のおかげで、それ以来何年にもわたって同じような不注意なエラーを何度も犯さずに済みました。
今回の件で作った格言に"テストされていないコードは動かない"というのがあります。
自分のコードをテストしてください。他の人にバグを見つけさせないようにしましょう。イライラした声を出さないようにしましょう!