

Features are faults - Athas
http://www.tedunangst.com/flak/post/features-are-faults

======
api
It's not just true for security, but also to some extent for usability.

At ZeroTier we develop our core network virtualization engine with a very
strict philosophy about settings and features:

* Any setting a user must adjust or manage to make things work is a bug. Everything must work instantly and reliably in any minimally functional environment, and installation must be single-step.

* Optional settings are suspect. They should be computed if possible.

* The best features are invisible.

* Any visible feature is suspect, especially if it's a special-case, workaround, or legacy support hack. A visible feature should only be added if an invisible feature or systematic fix eliminating its need cannot be found.

Simplicity is harder than complexity and minimalism indicates a more advanced
design. A longer feature list indicates an inferior product.

~~~
Athas
_Any setting a user must adjust or manage to make things work is a bug.
Everything must work instantly and reliably in any minimally functional
environment, and installation must be single-step._

This has its own problems, as you risk building hidden dynamic behaviour that
can behave unpredictably. The notion of "everything must work instantly" also
suggests enabling all possible services immediately, which is widely known as
a terrible idea security-wise (although it may well be usable).

~~~
api
Those are legitimate issues that you have to keep in mind for certain.

What I described is an ideal that is intentionally not reachable in practice,
like "the home is all of efficient, attractive, well located, and cheap." In
reality there are often trade offs.

