『プログラマーのジレンマ』を読んだ。

読み始めたら、止まらなかった。

「ソフトウェア時間」という言葉が、重くのしかかってくる。自分自身の経験にも、よく当てはまる。
予算は無制限に近い状態で、優秀な人材を集めていても、失敗する時は失敗するのだと認識させられた。

ここで、描かれているのは、「Chandler」と言うオープンソースの個人情報管理(PIM)ツールである。こう手のソフトは好きなので成功して欲しかったと思う。(まだ、失敗と断定するのは早すぎるかもしれないが、僕が使う事はなさそう)

失敗の原因を後知恵で言うのは簡単だと批判される事も多いけど、失敗から学ばないと、再び同じ失敗をする事になる。

正しい設計をする事は大切だが、コーディングにかかる事も大切だ。

P. 47

OSAFでは、全員の合意によって物事を決めていくため、決定が遅い。(中略) OSAFの問題は、コードを書けるところまで道を開くのがとても難しいことだ。

最初に正しい設計をしてから、コーディングというやり方だ。アジャイルなやり方は出来なかったのかなあ。
コードを書いてみないと分からない事も多いのだと思う。たしかに、コードの書き直しは嫌だけど、書き直しの時は、ずっと早くコーディングできるから、書き直しを厭わない方がいいのかも。

プロジェクトのオーナーが独断と偏見で決めなければいけない事がある。

P. 124

コードを再利用したいという一般的な希望を述べることと、実際に既存のコードの中から具体的な選択を行うことはまったく別の問題である。どのコードにも魅力と欠点がある。(中略) 誰も間違った選択はしたくない。

間違いは誰でも嫌なものだが、それでプロジェクトが延々と遅れてしまってはいけない。成功しているオープンソースのプロジェクトは、「慈悲深い終身独裁者」がこの問題を解決しているのだと思う。

P. 146

困ったことに、ケイパーはチャンドラーに関するあらゆることこに最終的な決定権をもっていたが、リポジトリの議論にはついていけないと感じたため、どの方法はやめてどの方法にせよという命令は下したくなかった。

この課題は、プロジェクトの技術的な課題の中では、最重要課題の一つなのだから、皆の信頼を集めている人が、その信頼を賭けて決定をするべきだった。

かなづちを持っていても、すべてを釘とみなしてはいけない。

プロジェクトの開始当時、ピア・ツー・ピアの技術に注目が集まっていた。
その影響か、チャンドラーでも、ユーザー同士のデータ交換にピア・ツー・ピアの技術を使おうと四苦八苦していた。

ピア・ツー・ピアの技術はお互いが、同時にオンの状態にないと使えない。電源がオフの状態の多いPCでは、データ交換のタイミングが非常に限られてしまうという根本的な問題がある。まあ、MicrosoftのExchange Serverが嫌で始まったプロジェクトだから、サーバーを使いたくないのは分かるけど。安価なクラウドなんてものは、この当時なかったのだから仕方がないのかも。

でも、向かない用途に技術を無理やり押し込もうとしていたんだと思う。

オープンソースと決めたら、最初からオープンにすべき。

ちゃんとした物ができてから、オープンにしようと考えていたようだけど、試行錯誤の段階からオープンにしておくべきだったのかも。

見せても恥ずかしくないものが出来てから公開したいというのは、よく分かるけど。批判を恐れずに公開した方が、プロジェクトが進んだのではないかと思う。

多くの事を一度にやりすぎない。

チャンドラーでは、

ピア・ツー・ピア方式で、特定のユーザー間のデータの同期をとる機能
様々なデータを一度に扱う機能
ユーザーが、プログラムを書かずにアドオンで機能追加を容易にできるようにする機能

と、一つだけでも大変な機能をいくつも同時に実現しようとしていた。

Unixの思想の、「一つの事を正しく行う」という言葉の重みを感じる。