バグがあれば、交換機では機械語の「パッチ」で解決する。リブートは御法度。バージョンアップでも止めない。深夜ドキドキやる作業だから、年一回でもやりたくはない。だから、小さな修正ならパッチのほうが早くて安心だ。しかし、開発中ならいつでもリブートできる。開発中はソースを直し、コンパイルし直せばいい。なぜパッチなのだ。新人のとき、そう考えた。
　全モジュールのコンパイルには一週間かかった。さらに、リストを印刷し直さなければならない。パッチなら一時間もかからない。だから、開発中もバグをパッチで「仮対処」し、試験の先を急ぐ。ソースを修正して「本対処」する。全モジュールをコンパイルし直したら、確認のため再び試験する。つまり、一つのバグに試験を二回。だから、交換機の試験工数は大きかった。
　武蔵野での初期開発では、二週毎に全コンパイルした。工期が厳しいため、当初計画の一カ月毎を短縮したいとメーカが提案してきた。試験は武蔵野だけだったから、印刷も一式で済んだ。だが試験後半、複数電話局に拡大すると、印刷発送がネックになり、延ばすことになった。
　あれから七年、品川に着任してみると、二カ月毎になっていた。計算センタも試験拠点も離れていたからだが、バグは多く、コンパイル周期が長いから、パッチは多くなる。二カ月間に五百件は作成していた。スキルあるベテランがパッチを作っているのだから、後輩を育成する余裕もなくなる。この二カ月毎を、毎晩にするまで三年かかった。ソースを修正して翌日試験できれば、パッチは不要だ。
　１モジュールのコンパイルは長くても一時間だ。それなのに全モジュールのコンパイル完了まで一週間もかかっていたのは、モジュール間参照の調整が問題だった。交換プログラムは百以上のモジュールで構成されている。他のモジュールの定義ファイルを「スタブ」と呼んだ。Ｃ言語のヘッダーファイルに相当する。モジュール本体を参照してもいいのだが、読み込むソースが膨大になる。やってみるとコンパイラがパンクした。それに、本体編集中は公開できない。（コンパイルエラーになってしまう）そこで、外部に見せる定義だけを抜き出し、スタブとして公開した。
　ＣＨＩＬＬコンパイラは、モジュール化した大規模プログラムを厳格にチェックするところが売りだ。それは正しいスタブが前提となる。全モジュールがスタブを提出し、コンパイルチェックしてエラーがなくなれば「スタブ凍結」となる。それを使って本体のコンパイルを始められる。このスタブ凍結まで、メーカの下っ端たちが走り回って調整、何日もかかっていた。
　研究所時代は原因を深く考えたことはなかった。「早く」「ちゃんと」メーカに指示するだけだった。また、納入対象ではないから、スタブが正しいか確認したこともない。メーカ担当者の「凍結しました」を信じていた。
　内製分が苦戦しているのを目の当たりにして、ジレンマに気づいた。スタブ凍結まで、自モジュールのコンパイルチェックはできないが、コンパイルチェックできないうちにスタブを作って提出しなければならない。
　内製を始めるにあたり、最新納入ソースを提出させたら、セミコロンが欠落していた。現場の作業精度は、その程度だ。編集ミスやファイルの取り違えは、日常茶飯事と思わねばならない。正しいスタブを保証する厳格な手順がいる。そして、その正しいスタブでモジュール本体をコンパイルすることも保証しなければならない。もしスタブと本体と食い違っていると、非常に見つけにくい潜在バグになってしまう。調べてみると、些細だがやはり不一致はあった。スタブを手でメンテしていては絶対にだめなのだ。スタブはモジュール本体からツールで作り直すこととした。
　提出された全スタブをコンパイルチェックすると大量のエラーが出る。大半は参照不足だった。あるデータ定義を参照するとしよう。そのデータに構造があり、内部に別のデータ定義が含まれている。それらを全て参照しないと「ＸＸＸが見つかりません」となる。しかし、他モジュールが定義しているデータを新規に参照するとき、その中にどんなデータが含まれているか分からない。コンパイルエラーをとりながら、定義を芋づる式に見つけて参照を追加していくことになった。
　データ定義を１モジュールに集約したのは、これを解決するためだった。それまでは、複数モジュールで（つまり複数社で）分担して定義していたから、全スタブが揃ってからでないとコンパイルチェックできなかった。そこで下っ端が走り回り、芋づる式参照解決をやっていた。しかし、全データ定義を集めたモジュールは、スタブ無しに単独でコンパイルできる。スタブ凍結の前にデータ定義を凍結することとした。そして、あるデータ定義を参照するには、どれだけの定義を参照すればいいか、データベースを用意した。これで、モジュール間の参照に関するエラーの大半は解決し、スタブ凍結から全コンパイル完までを一日に短縮できた。
　念のため、提出されたモジュール本体からスタブを作り直し、再度すべてコンパイルした。夜は全ワークステーションをコンパイルに動員できる。念には念を入れてコンパイルチェックしても、深夜０時を回るくらいには完了できた。リストはワークステーションで見ればいい。印刷し直す必要はない。こうして最後の壁、「メモリ割り付け」にたどり着く。
　新人時代、最初のメモリ割り付けに立ち会った。コンパイラが作った機械語に絶対番地を割り付けるリンケージを徹夜で動かした。某社の「割り付け職人」がさっそうと全社を指揮していた。
　品川にも割り付け職人はいた。ひょろりとして青白く、無口で目立たない男だった。全コンパイルが終わると、彼が一人ヘキサ電卓をたたき始める。（メモリ番地は１６進だからヘキサ）朝から晩まで黙々たたき続けて「割り付け図」を完成するまで数日。それに基づいてリンケージを動かすコマンドファイルを作る。リンケージすると大量にエラーが出る。千件はあった。エラーリストを配布し、点検してもらう。じつは大半が問題ないのだが、あればコマンドファイルを直し、再びリンケージ。これを数回繰り返す。そうして出来上がった絶対番地の機械語ファイルを試験チームに引き渡す。無事立ち上がれば職人の仕事は終わる。二カ月毎の一週間、終わると彼は休んでしまう。コンパイルやメモリ割り付けは雑用扱いで、主業務とは認知されていなかった。できて当然、失敗すれば怒られる。まるで非常勤のバイトのようだった。
　メモリ割り付けがバイトの秘術では困る。「持ち回りにしろ」と部長が命じたらしい。全コンパイルが始まると「割り付け、習いにやって来ましたあ」と地方から三人も出張してきた。いやいや、七つの地方で持ち回ったら、次に担当するのは一年以上先だ。絶対に忘れてしまう。それに手順を改良したいのに、秘術をデッドコピーしてほしくない。帰っていただき、品川に二名、コンパイルとリンケージの専担チームをつくった。ここから毎晩へ、二カ月毎のゆっくりした改良が始まった。