プログラミングは非常に専門的な作業であるため、社内の人間であっても、ある人の仕事の内容を正確に理解・評価することは容易ではありません。 そのため、プログラマに対する評価はその成果物、すなわち完成したプログラムの動作や、それができるまでの期間といったものを基準に行われることが多くなります。 そうなると必然的に、指定された要件を満たして「とにかく動くプログラム」を「短い期間」で納品できるプログラマが高い評価を受けることになります。

しかし、動作が同じだからといって、プログラムの「質」が同じだと考えるのは大きな誤り。 何故なら、プログラムの質の良し悪しは、動いているときではなく、何らかの理由でそれが動かなくなったときにこそ問われるものだからです。

ソフトウェアの動作はそれ単独で完結するわけではなく、それが使用するライブラリ, データベース, ネットワーク, ファイルシステムといった周辺要素からなる環境に依存しています。 「短期間で」「とにかく動く」ことを目的として作られたソフトウェアを注意深く観察すると、こうした環境が変化しないことを前提として設計されているものが多いことに気付きます。 例えば、

• 使用するデータベースは PostgreSQL で固定。
• 入力ファイル中の改行はCRLFであるものとする。
• 使用できる画像ファイルはJPEGだけ。

といった仮定のもとに作られたプログラムを目にすることは少なくありません。 このような設計に基いて実装されたプログラムは、その前提のどれか一つが崩れるだけで、正常に稼動をすることができなくなってしまいます。

一方、優れた開発者は、環境の変化による影響を最小限にとどまるようにプログラムを設計します。

• 使用するデータベースの種類が変わっても、設定ファイルを書き換えれば同じように動作する。
• 代表的な改行コードは (LF/CR/CRLF) に対応。
• 特定の機能に不具合が生じても、他の機能は引き続き利用できる。

もちろん、そのようなプログラムの開発は、設計・実装により長い期間を要します。 しかし、環境の変化は、それが予定されたものしても突発的なものにしても、いつかは必ず、そして一定の頻度で訪れるもの。 そうした状況におけるサービス停止の延長による損失や改修にかかるコストを考えれば、設計開発の時間を長めにとることは決して損とはならないでしょう。