組み込みでは、ソフトウェアの品質は、プログラマが制御対象についてどれほど理解しているかが大きく品質を左右する。*1
キャッシュを知らないプログラマがDMA転送を利用するプログラムを書いたら、「ごく希にデータが化ける」ソフトができあがることがあり、その頻度が少なければシステムテストを通って出荷されてしまう可能性だってある。
コレに対処するには、仕様書をじっくり読み、最低限「自分が何を知っていて何を知らないのか」を理解する必要がある。
でも、実際のソフトウェア開発で、ハードの仕様書を読むなんてフェーズはない。１週間かけて仕様書を読んだとして、「この１週間のアウトプットは？」とか管理者に言われても、アウトプットなんて何もない。インプットこそが成果だからだ。「判ったことをドキュメントにしろ」？はぁ？そんなに仕様書の劣化コピーが欲しいの？
ほかのフェーズでも同じ事が言える。設計フェーズでは、できた設計が重要で、それが頭の中にあるのか、裏紙にメモ書きされているのか、開くのに10秒かかるWordドキュメントになっているのかは大した違いではない。設計フェーズを「設計書を作るフェーズ」と定義すると、本質から大きく外れる。設計書のフォーマットを決めようモノなら、品質／工数のコストパフォーマンスは大幅に下がる。
結局、ソフトウェア開発において信じられる成果物は動いてテストされたプログラムだけなのだ。
