A random collection of ideas about software tools.
Prime Directive
The Linux Hater has blogged :
'...I've found samba to be pretty solid code... when I can configure it. And that's what it really comes down to. The best code in the world won't change the world if people can't use it.'
Next, take the word 'samba' out and insert the name of another component.
Keep it DRY
DRY (Don't Repeat Yourself) applies to tools as well. In general, whenever there are reasonable default values/choices that make sense, the the tools should use these. Of course, users might want to change these default values/choices, and tools should enable that, but users should not have to
Provide readily available information
Repeat answers already provided (exception: confirming operations for things like password changes and so on)
Substitute for actions/choices/values that the tool could have at least guessed
Forgive Features
This theory says that users will forgive missing features in a high quality software package (or will accept having to wait for the desired features), but will reject a full-featured software package that is of low quality.
In more detail:
A person (customer, user, manager, QA engineer...) who is evaluating a software package and who will make some judgment about the fitness/completeness/quality of the software package is called the "evaluator." The evaluator will have a much more favorable impression if the software package has high quality but is missing certain features than if the features are present but the software package quality is low. This is especially true for software packages that the evaluator expects will continue to evolve. In essence, the evaluator will forgive missing features in a high quality software package because the impression is that the software package has made a strong start, and hence the future is promising. A low quality software package, no matter how full featured, gives the impression of being "scattered" and does not build confidence in future performance. Of course there is a minimal set of features necessary to be considered credible: I call this the Minimal Credible Feature Set (MCFS). A secret is that the MCFS is often much smaller than evaluators would like to have you believe.
Although it is not rational to assume that current high-quality software packages missing features will continue to evolve to include the missing features while retaining the level of quality, it seems that the lure for believing in quality over features has to do with the nature of each. Features are more discrete -- a software package can do something or it can not -- and hence it is easier to imagine a future in which the software package will have the feature. Quality, on the other hand, is open-ended: we do not know how many bugs lurk in a certain software package, and we do not know when new bugs will surface. This lack of definition leads to uncertainty. This uncertainty makes evaluators uncomfortable with a software package, because they can not clearly imagine a future without this uncertainty.
It is therefore imperative that a software package maintains a reasonable level of quality throughout its evolution, otherwise evaluators will reject that package.
Comments