Configuration vs. Engineering (was Re: [linux-elitists] Re: Yet another mozilla atrocity)

Karsten M. Self kmself@ix.netcom.com
Tue Oct 7 00:01:01 PDT 2003


on Mon, Oct 06, 2003 at 08:09:17PM -0400, Mister Bad (mr.bad@pigdog.org) wrote:
> >>>>> "KMS" == Karsten M Self <kmself@ix.netcom.com> writes:
> 
>     KMS> [...] minimizing complexity, maximizing flexibility [...]
> 
> I have a big amen for everything you said, BUT... I think that these
> two principles can sometimes be at odds.

You _think_?

Hell yes they are.  That's why it's called design, and not throwing shit
on a pile.

There are trade-offs.  The two aims:  minimal complexity, maximized
flexibility, *are* at odds.  This doesn't mean there isn't a middle
ground which can't be steered through.  Jeff is intent on steering with
rudder hard port, and gets confused when we point out he's navigating in
ideological circles....


> All too often in the Free Software development process design or
> algorithm decisions are put off -- for reasons of egotism or for other
> points -- by implementing both designs and providing a configuration
> switch to choose between the two.

True, but...

...the design process is open.  Someone can come along with a solution
which preserves the flexibility but improves simplicity, or vice versa.
And in the competitive marketplace of ideas and adoption, that design is
adopted as preferred.  I've seen it before.  It's the basis for more
than a few of my own software picks.

Yes, there are periods of poor attention to overall design.  They
usually shake out though.

> This can sometimes give needed control to users and administrators,
> but more often than not it simply increases code complexity (with all
> the consequent maintenance ills) with little needed flexibility.
> Administrators and users don't really need to choose between an O(N^2)
> and O(NlogN) algorithm. The better choice should be made at
> engineering time, and the code for the less desirable choice should be
> eliminated altogether.

Depends on the constant involved.  If N is typically small and the
constant large, there may be a reason to go with O(N^2) in cases.

Still, I'm with you:  a runtime determination can be made based on N to
choose between algorithms.  My own software designs (specific to data
analysis) actually focus explicitly on this sort of thing.  But you're
also right:  this is a decision that needn't involve the user.

More to the point, as with (IIRC) Martin's choke example:  this is a red
herring (as you note).  The configuration settings I'm thinking of
involve presentation or visible behavior -- fonts, screen resolution,
refresh, colors, symlinks, keybindings, aliases and shell scripts for
specific tasks.  These are tools that _do something_ for me -- which is
immediately visible.

A choke doesn't really do anything for me, directly.  Nore does a choice
between an O(N^2) vsl O(NlogN) algorithm.  Both are concerned with inner
workings of a mechanism, in which an engineering preference can be
readily determined, with a decision cycle _far_ shorter than I can make.

There _was_ a time when a choke was an appropriate control:  when the
engineering capability didn't exist to create a solution which was
sufficiently better than a typical human could affect.  Note though,
that my car, er, truck, _does_ have a gearbox.  And I vastly prefer this
to automatic transmissions:  I have a better foreknowledge of what I
want, what the road ahead is throwing me, and how my car will respond in
gear, than an automatic would have.  If not most of the time, then at
the times that matter most.


Peace.

-- 
Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    Bush/Cheney '04: Get used to it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20031007/11ffc879/attachment.pgp 


More information about the linux-elitists mailing list