From: Robert Tweed <robert_at_killingmoon.com>
Date: Tue, 20 Aug 2002 05:09:09 +0100

----- Original Message -----
From: "Psyco Dedman" <psyco_at_psyco.yi.org>


> I disagree... the problem is that everybody uses a *different* 10%...

The problem is when you have a large number of features that are only used
by a tiny minory of people. In the case of the office analogy, it's actually
the same 10% subset that most people tend to use, not an entirely different
subset. Most of the features of office are completely unknown to most users:
it's not simply a case that people choose to use different features because
they work differently, in fact most users do exactly the same jobs in
exactly the same way.

> i'd much rather see "bloatware" than lowest-common-denominator...
> the better way to go IMO is a thought out, simple, and flexible system
> for the options, such that the user gets to what they want...

That is basically what I am advocating (apart from the bloatware part).
"Well thought out" implies not just bolting on every possible option you
could possibly think up, but rather sitting back and choosing the *best*
options to produce a simple but effective system that does what people want
with an intuitive interface.

Just because someone thinks an idea is great, doesn't necessarily mean that
they have thought about it properly. They may eventually think of a better
way to tackle the same problem (and a lot of interface related problems
could be tackled by simply organising MP3s better, which is not IMO, the
sort of thing that should be a priority). If everything just goes in the mix
without any real consideration, you just end up with an unfocused jumble
that benefits no-one.

I'm quite happy with the way things are going just now, because there are
people willing to say "no" to ideas that simply waste space in the finished
program.

I would find the addition of *compile* time options far less objectionable,
but there is no point in forcing options on everyone if only a few people
are ever going to use them. Unneccesary options should always be off by
default, so if anyone really wants them, they can recompile with that option
included.

However, this does still increase the maintenance burden somewhat for the
developers, unless all these options are going to be marked "unsupported,
use at your own risk". If something is going to add little or no benefit,
what is the point in causing all the extra work required to implement it?
The workload extends beyond one person simply submitting new code, since
every piece of code in a system can potentially affect every other piece of
code: a fact often overlooked by inexperienced hackers.

In fact, in writing this I just thought of a new term: optionware. Most
open-source software is optionware. It is stuff that tries to be everything
to everyone, or as it is known to designers "jack of all trades, master of
none" design.

Take PHP, for instance. There are soooo many options, and soooo many
libraries that it is almost impossible to write 100% fault-free, portable,
secure code in PHP. Much as I like PHP, this is it's biggest downfall. PHP
is optionware.

I could pull many more examples from the world of open source, but it's a
simple point: more options = less intuitive interface, and often a less
efficient program.

- Robert
Received on 2002-08-20