ソフトウェア技術者はまずソフトウェア技術のことをもっと知ったほうがいい

ソフトウェア開発者は製造業のことを知った方がよいから。製造業のことは詳しくは知らないので知った方がよいかどうかの判断はできませんが、ちょっと気になったところ。

我々の作るものには物理的制約がないこと

はよく言われるけど、そんなことないでしょう。少なくとも光のスピードを越えられない以上、計算速度の限界があります。それに実際問題として、速度と空間はトレードオフの関係にあることも忘れてはだめでしょう。 時間と空間(記憶容量)は我々に制約をかけてます。メモリ上なら(cacheにのっていればさらに)高速に計算できますが、メモリ(or cache)の容量は限られています。それ以上のデータを扱おうとすると ディスクもしくはネットワーク越しのサーバーを使わざるを得なくなりますが、それはとても遅いということはソフトウェア技術者ならば当然知っておくべきのことのはず。ディスクアクセスはそれこそ物理的制約(ヘッドのシーク)が効いてきます。 アクセスにどれくらい時間がかかるかについては"Numbers Everyone Should Know"としてよく知られています(See CS343 Spring 2007) それに、メモリがいくら速いとしてもそれなりの規模のデータになれば、適切なアルゴリズムを使わないと実用的な速度で使えるソフトウェアにならないことも忘れちゃだめです。 「大半のレイヤーが人為で作られた不確定要因だらけのソフトウェア開発」という不確定要因とは何でしょう。 設計・実装がしっかりできてないだけなのではないのですか？ソフトウェアをどのように作るべきか知らない人が設計したりしていませんか？わかりやすくメンテしやすく堅牢で性能のでるプログラムを書くための方法を知らないで、とにかく最初に思いついたコードを書いているだけではありませんか？トレードオフを考えよりよいコードにできないか検討して、改善していますか？なにか不可解なことがおこっても「相性のせいで」とか「バッドノウハウ」とかですませてしまって、深く追求していかないせいではありませんか？ コンポーネントが十分に堅牢かテストしていますか？ 書くべきドキュメントやコメントを書かなかったり、逆にテストコードで書くべきことを無駄にドキュメントにしていませんか？（不安定な）コンポーネントを「なんとなくこうすれば動くから」というようなやりかたでつみあげていっているから不確定要因だらけになってしまっているのではありませんか？ ソフトウェア技術者ならば、ソフトウェアを作りあげるための部品・材料になにがあるか、その特性、その使いこなし方のことをまずもっと知るべきなのです。ということを最近ますます思うようになっています。