Close kin to the programmer tendency to build overelaborate
castles of abstractions is a tendency to overprotect others from the
low-level details. While it's not bad practice to hide those details
in the program's normal mode of operation
(fetchmail's -v switch is
off by default), they should be discoverable. There's an important
difference between hiding them and making them inaccessible.
reveal what they are
doing make troubleshooting far more difficult. Thus, experienced Unix
users actually take the presence of debugging and instrumentation
switches as a good sign, and their absence as possibly a bad one.
Absence suggests an inexperienced or careless developer; presence
suggests one with enough wisdom to follow the Rule of
The temptation to overprotect is especially strong in GUI
applications targeted for end users, like mail readers. One reason
Unix developers have been cool toward GUI interfaces is that, in
their designers' haste to make them ‘user-friendly’ each one
often becomes frustratingly opaque to anyone who has to solve user problems
— or, indeed, interact with it anywhere outside the narrow
range predicted by the user-interface designer.
Worse, programs that are opaque about what they are doing tend
to have a lot of assumptions baked into them, and to be frustrating or
brittle or both in any use case not anticipated by the designer.
Tools that look glossy but shatter under stress are not good long-term
Unix tradition pushes for programs that are flexible for a
broader range of uses and troubleshooting situations, including the
ability to present as much state and activity information to the user
as the user indicates he is willing to handle. This is good for
troubleshooting; it is also good for growing smarter, more
[an error occurred while processing this directive]