やり遂げられる (2003)
(multicians.org)- Honeywell Cambridge における Multics ファイルシステム の改編過程で、André Bensoussan は中核サブシステムである VTOC manager を担当し、設計からテストまで進めた
- このモジュールはファイル記述情報をディスクとメモリの間で移動させ、バッファプールとディスク空間まで管理する必要があり、実質的に 小さな仮想メモリマネージャ に近かった
- André は端末の前で直接コーディングせず、鉛筆で図とコードを磨き上げながら、状態情報を保持しつつ 対称的な設計 を作ろうとした
- 最終原稿を入力した後、最初のコンパイルで出た問題は タイプミス 3 件 だけで、システムにバインドした実行も最初の試行で成功した
- その後に見つかったバグは、Tom Van Vleck がエラー処理手順の 呼び出し順序 を誤って伝えたことから生じた 1 件だけで、プログラム自体の完成度は非常に高かった
Multics VTOC manager の作業
- André Bensoussan は Tom Van Vleck とともに Honeywell Cambridge で Multics オペレーティングシステムの作業をしていた
- ファイルシステムの大規模な変更には VTOC manager というサブシステムが必要だった
- ファイル記述情報をディスクとメモリの間で移動
- 共有メモリの バッファプール を管理
- ファイル情報用のディスク空間を管理
- こうした役割のため、VTOC manager は小さな 仮想メモリマネージャ のように動作する必要があった
- André はこのモジュールの設計、実装、テストを担当した
鉛筆で完成させたプログラム
- André はまず机に向かって多くの 図 を描いた
- すべての状態情報を盛り込みつつ、見栄えがよく対称的な形を望んでいた
- スケジュールの都合でコードを書くのが遅れていると周囲が心配するほどだった
- コーディングも端末ではなく 鉛筆 で進めた
- タイピングの手助けを断った
- 一部を書き直し、清書し、消して、修正しながら最終原稿を作った
- 最終的な鉛筆原稿を端末にすべて入力したあと、最初のコンパイルは失敗したが、タイプミス 3 件 を直したあとコンパイルに成功した
- システムにバインドして実行すると最初の試行で動作し、その後 VTOC manager はずっと完璧に動作した
- 見つかった唯一のバグは、André が尋ねたエラー処理手順の 呼び出し順序 を Tom Van Vleck が確認せず推測で伝えたことから生じたものだった
- そのエラーパスを初めてたどったときにクラッシュが発生した
- それ以外にプログラムの問題はなかった
1件のコメント
Hacker Newsの意見
彼がそれを実現できた主な理由は、要件が非常に明確に定義されていたからだと思う
今日のソフトウェアにバグが多く遅い大きな理由は、実際に何を作っているのか誰も分かっていないか、分かっていても「アジャイル」のせいで絶えず変わるからだ
開発者に明確なAPIとよく定義された基準を与えれば、たいていは非常にうまく動くコードを書く
要件とは、リストやチケットをカンバンボードに並べることではなく、作る対象のドメインを実際に学ぶことだ
理解していない領域でも作ることはできるが、成果物はゴミになりがちで、そのゴミを書く過程を、ドメイン上の課題とあり得る解決策を学ぶためのドラフト作成として受け止めるならそれでよい
品質に近道はない
ステークホルダーなら、アプリケーションを作る人にアクセスできるべきであり、彼らがドメインを理解しているか確認すべきだ。しつこく邪魔しなくてもそれは可能だ
流行語を並べ立てる大ぼら吹きには注意すべきだ
デザイナーやプログラマーなら、ステークホルダーとドメイン専門家が積極的で深く関与しているか確認すべきだ。そうでなければ、要件と理解を引き出すのは歯を抜くように難しくなる
ステークホルダーの中には、問題を解きたいとすら思っていない人もいるかもしれず、まったく別の方向を望んでいたり、政治的な理由ですねていたりすることもある。怠惰または無関心なステークホルダーほどプロジェクトを沈めるものはない
ステークホルダーは自分が何を望んでいるか分かっていないのに、ランダムに見える追加機能や大幅な変更を要求する
このツールでやるべきでないことまで無理にやろうとして、膨大な例外処理が必要になる
デザイナーは、必要な機能、既存システムの動作、ステークホルダーの要求と衝突する設計を作ることが多く、システム各部分を開発するチームは十分にコミュニケーションしないままサイロの中で作る
まずく設計された「アジャイル」プロセスは、怪しげな見積もりポイントに基づいて、あらゆるものを特定の期間内に押し込もうとする
結局、こうした問題がシステムを意図どおりに動かなくしたり、バグの塊にしたりする
要件が明確で変わらず、プロジェクトメンバーがよくコミュニケーションし、プロセスを完全にコントロールできる環境を作ればうまくいく。元記事の事例もそう見える
大企業で主に働いているが、入ってくる仕事の90〜99%は平均的なケースに当てはまる
ところが3年に一度、しかも月食と日食が同時に起こり、森で魔女たちが呪文を唱える頃に発生するような、ユニコーンみたいな特殊ケースが無数にある
こうしたケースを手作業で処理せずコードに実装しなければならないのでバグが生まれ、レビューして保守するコードがはるかに増える
保守の話は始めないでおこう。痛いところだ
要件は常に変わる。それは自然の力のようなもので、全員が最初から何を作るか知っていて、完全に仕様化されたAPIを受け取り、洞窟に入って実装だけすればいい世界などない
現実は絶対にそうは回らないし、そういう条件が必要なら、ソフトウェアエンジニアリングは向いている職業ではない
ユーザーがいなければ、私のソフトウェアは完璧なのに ;)
ソ連から亡命した人と働いたことがある。彼は、ソ連のプログラマーが優秀だった理由は、コンピューターへのアクセスが非常に限られていたからだと言っていた
鉛筆と紙でプログラミングしなければならないなら、最初の実行で動くように作りたくなる
偶然にも、私たちはHoneywellで働いていた
だとすると、これは良い教育方法だったのか、それとも動機づけの低い人をふるい落とす良いフィルターだったのか?
学校では授業中にコンピューターを使えなかったので、紙にプログラムを書き、さらにはデバッグすることにも慣れていた
家に着いて入力し実行してみて、以前読んだMulticsの逸話を再現できるか気になっていた
最初のコンパイルは失敗したが、変数名を1つ直した後は完璧に動いた
数年間は、編集→コンパイル→出力のループで、端末よりもリスティング出力のほうがはるかに良かった記憶がある。コードを効率的に見て移動し修正するのが難しかったからだ
より良いビジュアルエディタ、より大きな端末、より速いコンパイルと実行が出てきて、最終的には改善された
たとえるなら初期の火器に似ている。湿った火薬、不安定なフリントロック式の点火、銃身にすべてを押し込まなければならない方式のせいで、長弓から移行する過渡期が非効率だったのと同じだ
この記事の以前のHNスレッドに、Andréと一緒に働いていたjrd259アカウントの良いコメントがある: https://news.ycombinator.com/item?id=18415231
広い机と通知のない個人作業スペースがどれほど重要かに関する内容だ
私の人生で、紙にプログラミングしたことが2回あったのを思い出す
1回目は10〜12歳くらいの頃だった。コンピューターもスマートフォンもない祖父母の家に行ったら、黒と赤をスイッチで切り替えて打てる機械式タイプライターがあった
当時の主な趣味が Turbo Pascal だったので、後で家に戻ってPCに入力して実行する Pascal プログラムをタイプライターで書いた
祖父母の家に1週間いたので、十分に考え、手でデバッグし、間違った部分を打ち直す時間があった
2回目は、自分が作った難解プログラミング言語 Ziim(https://esolangs.org/wiki/Ziim)と、そのページにある二進加算関数に関することだった
その関数は巨大で複雑で、バグがあった。インタープリターで実行してみたのでバグがあることは分かっていたが、どこが問題で、どう直せばいいのか分からなかった
ちょうど約6時間の長距離バスに乗る用事ができ、デバッグには完璧な機会だった
Ziim の加算関数を鉛筆で方眼紙に写し、バスの中で一段階ずつ手で実行した。バグを見つけて修正でき、関数の配置をすべてやり直す必要があった
簡単なやり方をする能力をあえて制限すると、ときにはよく練られたコードにつながる、という教訓のように思う
とはいえ普段からこうするわけではない。適当にスニペットを書いて反復したり、デバッガで1行ずつ実行したりもすぐにする。考え直すべきかもしれない
だがすべての作業を紙でやると、結局はコンピューターに直接やるのと大して変わらなくなる。全部を書き出してしまい、その抽象化と慎重さを失ってしまう
私が始めた頃は「大型コンピューター」時代の末期だった
昔の「プログラマー」はたいていデータ入力事務員に近く、しばしば女性だった
ソフトウェアを書く人たちは、タバコの煙でいっぱいのオフィスで紙にプログラムを書いていた
コンピューティング時間は高価で貴重だった。実行中にバグが出ると、再びデータ入力の時間を取り、さらにCPU実行時間を取るまでは修正する機会がなかった
そのため、二度測って一度で切るというアプローチが奨励された
当時のソフトウェアの大半は、今日では当然とされるものに比べるとかなり質素だったので、そうするのはより簡単だった。また、ソフトウェアの入出力は極度に制限されており、UIという言葉さえなく、周辺機器の接続は大仕事だった
最近はソフトウェアを書くとき、よく「壁に投げて何がくっつくか見る」ようなやり方をする。半分できたコードを書いて IDE でデバッグする方が楽だ
私のソフトウェア開発は反復的な方で、ここに書いたことがある: https://littlegreenviper.com/miscellany/evolutionary-design-...
大学の課題で簡単なOSカーネルを書かなければならなかったことを覚えている
Cもよく知らず、カーネルが何をするのかも理論以上には知らなかったが、タスク管理のために数百行のCコードを書かなければならなかった
このプログラムが動かなければ並行コードなのでデバッグする方法はほとんどなく、バグは正体不明の競合状態として現れるだろうと思っていた
システム全体を推論し、数日かけて小さく独立した関数群をじっくり考えながら書いた
それからコンパイルして実行したところ、当然の「セミコロン抜け」コンパイルエラーを直した後、初回実行で動いた
印象的な成果が投稿されるたびに、コメントはたいてい粗探しをする。もうやめてほしい
新しいOSのための仮想メモリマネージャを設計する人ではなく、子どもや高齢者に広告を見せるためにSQLクエリをHTMLに変換する機械の歯車にすぎない
皮肉っぽく、苦々しくならざるを得ない
実際には、そうすべきではない。議論とはまさにそういうものであるべきだ
ある程度は正しいが、前向きな方向に転じるより良い問いはこれだ。今日の企業環境で、似たような成果が可能な状態にどうやって到達できるのか？
こういう反応を見るたび、だいたいそうだ。ユーザーによるモデレーションというふるいが、より良いコメントを上に上げるのに少し時間がかかるだけだ
この人が私の経験した挑戦に直面していたら、そのままへたり込んでいただろう
当時のソフトウェアはずっと小さかった
最近はおもちゃのようなプログラムより少し大きいだけで、たいていのプロジェクトはメガバイト単位になり、単一ファイルとして「書き下ろす」ことは不可能
これは今日たいていの人が扱っているものより大きく複雑。今日の仕事の多くは、CRUD/REST のようなものをつなぎ合わせる大げさな接着コードに近い
プロジェクト全体のコード行数よりは少ないかもしれないが、人々が扱う単位よりは大きい。しかもこれも OS 全体のコードの一部にすぎない
これは「ファイル記述情報を管理するマネージャ」全体である。ファイル情報をディスクとメモリの間で運び、共有メモリのバッファプールを管理し、その情報のためのディスク領域も管理しなければならなかった
いま大半のプログラマーに、同じ要件とセマンティクスを持つものを自分の選んだ言語で今日書いてみてと言ったらどうなるだろうか
たいていはそれを想像する段階から迷子になるだろう。まして紙に書いて入力し、動くようにするのはなおさら難しい
そのうち少しは電子部品の URL だが、ほぼ 90% はただの英語テキストだ。さらに 10% は他人の文章、Web ページ、メーカーのアプリケーションノート、書籍などからの引用である
単一ファイルで、今年の残り期間はもちろん、おそらくずっと単一ファイルのままだろう。同じペースで続けば 12 メガバイトになる。不可能なことではまったくない
興味があれば git clone http://canonical.org/~kragen/sw/leatherdrink.git すればよい
現在は avr ツールチェーンをコミットしてあるのでほぼ 200 メガバイトあり、写真・動画・回路図のようなものも含まれている
プログラミング言語なら月ごとの増加バイト数はもっと少ないだろうが、おそらく 5 倍ほどの差かもしれない
André Bensoussan が書いたコードはここにある: https://multicians.org/vtoc_man.html
仕事を始めようと机に座り、気が進まなかった作業を片づけようとした瞬間、当然のように気がそれて reddit や HN でニュースを見たくなった
HN を開いたら、最初のタイトルがこれだった
「できる」
やる気が出た
追伸: もちろん記事も読んだ :)
「André は鉛筆以外に何の道具もなしで、どうやってこれをやったのだろう？」
14 歳で高校に入ったとき、プログラミングの授業ではコードの大半を紙に書いていた
貧しい国の貧しい子どもで、家に PC がなかっただけでなく、学校のコンピュータ室にあった数少ない「コンピュータ」も、当時使っていたプログラミング言語である Turbo Pascal を実行できない ZX Spectrum のクローンだった