Fighting feuture creep

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > The simplest way to get to a consistent UI design was to remove all
> > command-line options.  Which is a good idea anyway - less to remember, and
> > the command keystrokes cover the functionality. 
> 
> I think you are rationalizing a bad decision.  By that logic, I could improve 
> lots of programs by removing features: less to remember.

Yes, you could. I often improve programs in exactly that way, and I'm
planning to do it to ntpd again soon.  One of my minor todos is to
check for command-line options that are no longer needed because we've
dropped support for broadcast and multicast client modes, and remove
those.  I know of at least two more options we'll be able to remove
when I rip out interface scanning.

Complexity is a cost.  The Unix design tradition has few more dedicated
partisans than me, but that does not blind me to its flaws.  One of the
largest of these flaws is a strong tendency to underweight the costs of UI
complexity.  A related one is the belief that configurability is a license
not to think hard enough about what the right thing is.

These errors have a cumulative effect over the life of programs.  They
result in an accumulation of marginal "features" and configuration switches
of dubious value, each one of which adds complexity - not only in itself
but in interaction with other marginal features, generating costs that
are not merely O(n) in the number of protruding frobs but O(n**2).
Ultimately these costs net out as higher defect rates.

Complexity creep goes hand in hand with an increase in cognitive load
on those who must use and maintain the software.  That cost nets out
as higher operator- and developer error rates.

Because programmers in the Unix culture have only weak doctrinal
defenses against this kind of complexity creep, one of the most
valuable qualities a Unix systems architect can cultivate is a
relentless drive to pare back and simplify. And this has to
operate in small things as well as large, because when you start
making excuses for bloat you put yourself in a mental state
where bloat becomes *difficult to see*.

"Perfection is achieved, not when there is nothing more to add, but
when there is nothing left to take away."  I wasn't being cute when I
chose that Saint-Exupéry quote as the project motto.  It was a
considered, hard-nosed statement of intention, and not merely some
vaporous aesthetic kind of intention either. Minimization of
complexity is minimization of expected defect load. This was the
premise I have been executing on ever since.

Reduce sttack surface, reduce complexity, reduce features, strip down
to the essential core.  As in large, so in the small as well - every
command-line switch I can strip out is a victory holistically
connected to the larger program.

If I am rationalizing a bad decision, it is exactly the same kind of
bad decision that has shrunk the NTPsec codebase to 27% of its original
size while preserving function.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>