Many pressures tend to make programs more complicated (and
therefore more expensive and buggy). One such pressure is technical
machismo. Programmers are bright people who are (often justly) proud
of their ability to handle complexity and juggle abstractions. Often
they compete with their peers to see who can build the most intricate
and beautiful complexities. Just as often, their ability to design
outstrips their ability to implement and debug, and the result is
The notion of “intricate and beautiful complexities” is
almost an oxymoron. Unix programmers vie with each other
for “simple and beautiful” honors — apoint that's
implicit in these rules, but is well worth making overt.
Even more often (at least in the commercial software world)
excessive complexity comes from project requirements that are based on
the marketing fad of the month rather than the reality of what
customers want or software can actually deliver. Many a good design
has been smothered under marketing's pile of “checklist
features” — features that, often, no customer will ever
use. And a vicious circle operates; the competition thinks it has to
compete with chrome by adding more chrome. Pretty soon, massive bloat
is the industry standard and everyone is using huge, buggy programs
not even their developers can love.
Either way, everybody loses in the end.
The only way to avoid these traps is to encourage a software
culture that knows that small is beautiful, that actively resists
bloat and complexity: an engineering tradition that puts a high
value on simple solutions, that looks for ways to break program systems up
into small cooperating pieces, and that reflexively fights attempts to
gussy up programs with a lot of chrome (or, even worse, to design
That would be a culture a lot like Unix's.
[an error occurred while processing this directive]