39は多いので全部は紹介しないけど、これはAPIとかフレームワークに限らず、ソフトウェアデザイン全般に有効であろうと思うものがほとんどであった。
少なくとも言語設計には応用可能である。まあ、考えてみれば、言語を構成するものは文法とライブラリであるが、割合としてはライブラリ(つまり、API)なのであるから当然と言えば当然か。
Rubyを使うのはその柔軟性や生産性のためで、他の言語でそれを達成するためには、結局自分でそれらを実現しなければならない。野良フレームワークでそれを実現しようとすると
破目になってしまいがち。つまり、Rubyが遅いのはそれなりに理由があるということ、という話。
実際にはRubyが遅いのには別の理由(まつもとの能力の限界)もあったりするんだけど、それはそれとして、グリーンスパンの第10法則というのはそうやってあちこちで繰り返されるんだねえ。
顧客にマジカで分析してもらって、タスクカード1枚8万円と言う値付けで開発するというビジネスモデルを採用、もう人月モデルには戻らない、という話。
諸悪の根源は見積もりの不確定さだと思うので、顧客によるある程度の分析が行われることで、見積もりの確度が上がれば、人月モデルとサヨナラできるのかもしれない。
予想される問題は、このビジネスモデルは「顧客の怠惰さ」を過小評価している点ではないか。
SI屋: まず、業務を分析してください。その結果のタスクカード1枚ごとに8万円で開発します。
顧客: えー、分析ぃ？ めんどくさい。そんなにコストがかけられないから開発をお願いするわけで。分析も設計もそっちでやってよ。
これもまた、見積もりの問題である。