Coders at Work

発売日(5/25)に買いに行って、仕事の合間を縫ってやっと読み終えた。
あまりにためになる言葉が多すぎて、簡単に感想を書くのすら難しい、ただ、心に残った一節をここにメモする。技術的に素晴らしい話は本書の中に多々ある。気になった人は本文を読んで欲しい。

ピーター・ノーヴィグ
私が関わった一番大きなバグは、（中略）1998年の火星プロウラムの失敗です。1つはヤード・ポンド法かメートル法かという問題でした。
(中略)
二人の人間が別々のチームに属していて、一緒に並んでランチを取ることがありませんでした。もしそうしていたなら、このような問題は起きなかったと想います。しかし、そうする代わりにこんなメールを送るわけです。
「どうも測定があっていない気がする。ほんのちょっとずれている。大したことないから、たぶん問題ないと思うけど・・・」
ーそれは航行中の話ですか？
そうです。航行中に捉えられるチャンスは何度もあったんです。彼らは何かが変だとは気がついていて、メールを送ってもいるのですが、バグトラッキングシステムには入れていませんでした。
（中略）
だから、コミュニケーションの問題だったわけです。これはまたソフトウェア再利用の問題でもあります。

NASAはメートル法を期待しているのに、JPLとロッキード・マーティン社はヤード・ポンド法でプログラムしたらしい。この問題は「既に航行中のロケット」で発覚した（もう引き戻せない）ところが興味深い。
運用中にバグに気がついた担当者がどういう行動を起こすべきか、普遍的な話だと思うが誰も正解はわからない、NASAの結論に注目すると

ー　あの報告書を読んでNASAの姿勢に打たれました。「問題はソフトウェアのバグだったわけだが、宇宙船が期待したように進んでいないことに気づけるチャンスはたくさんあり、我々は気づいているべきだった。たとえ入ってくる数値が間抜けなソフトウェアの不具合による全くいい加減な値だったとしても、我々はそれを正しているべきだったのだ」見上げたものだと想いました。

プログラムが正しいと過信しない姿勢は大変難しいが大切なことである、凄い強さだ。
（安易に停止するのが正しいわけではない、そこからどう立て直すかが重要なのだ、という姿勢には本当に尊敬したい）
このあとにも、シャトルの飛行制御のソフトウェアの話などが続く。

本書を読むのならMasterMinds of Programmingを読んでからにしたほうがいいと思う。あの本に、出てこないガイ・スティール（←オモロイ）や、ケン・トンプソン（←すごくオモロイ）らの話が読める。読み進めるのは時間がかかるが、大変お得な本だと思う。