[Tfug] Stored settings

[Bexley Hall]

Hi, Rob,

> >> Minimally, you should have a formal specification of the data
> >> format, and, ideally, a robust set of tools for performing IO,
> >> validating, and transforming your data.
> 
> On Tue, Dec 09, 2008 at 12:54:48PM -0800, Bexley Hall
> wrote:
> 
> > Exactly!  That is the point of the question.  If I bundle ALL of
> > these issues together in the interface *to* the "config database",
> > then I achieve all of the goals in a manner that is maintainable
> > and far more usable (to the end user) than the traditional approach
> > of keeping them all as separate -- though logically linked --
> > entities.
> 
> You, more than anyone else, should know what is "the right thing
> to do".

<frown> Well, if I was 100% sure, I wouldn't ask!  :>  The problem
is anticipating how users will interact with devices.  I base my
approaches on how I *think* a "rational" user would want a device
to behave.  But, people always come up with unusual ways of using
things that aren't anticipated... :-/

> But since your question was phrased in general terms, my
> answer was, too.
> 
> > I.e., having a specification is only meaningful if the user has
> > access to it, if it is written in a form the user can easily
> > parse, *and* if it is kept in lock-step with the actual implementation!
> > If any of these get out of sync, then they are worse than useless
> > as they will only ADD to the user's confusion.
> 
> Once again, it is for you to decide what is best for yourself, so
> don't take this the wrong way.  But I maintain that any software that
> is destined for release should be documented in exacting detail,
> particularly the data that it accepts, and the data it produces.  Yes,
> this requires significant effort.  Yes, software updates may require
> documentation updates. Yes, failure to do so may be thoroughly
> misleading, and elicit a steady stream of bug reports and
> death threats.  Oh, well -- now you're in the big leagues!

You're preaching to the choir  :>   I start each project with a
Preliminary Specification.  Then, once that *seems* finished, I
write the User Manual.  This is usually the best way to flesh out
any details that may have been omitted in the Prelim Spec.  I.e.,
"Well, what happens if I *don't* 'Answer YES or NO'?", etc.
Once the manual is done, I go back and "fix" the Specification
so that it covers all of these contingencies.

This puts a *huge* up-front load on the project but, thereafter,
the implementation is usually a piece of cake -- all of the
"thinking" has already been done!

I'd estimate that I spend almost 50% of my time "up front" on
paperwork; 30% writing code (assuming the hardware is already
designed) and 20% on validation.  The 20% number sounds bad
but having detailed specs to work from means I can often do
much of the traditional "testing" during the code writing phase.

Having documents up front is also a win for marketing droids,
etc.  They can't later claim they didn't know a certain capability
or feature was "missing", etc.  And, they can start positioning
for product introduction, support, etc.

> Allow me clarify my point in relation to your original
> post: Other than aesthetics, I don't think it matters if you say...
> 
> "EraseBootDriveOnPowerUp = Never"
> 
> or
> 
> "EraseBootDriveOnPowerUp = 3"
> 
> or
> 
> "ButterScotchCookies = HidyHo"
> 
> or even
> 
> "ConfigurationOption612365 =
> 24.32.16.hike.hike.hike"
> 
> ...so long as somewhere there is something written to the
> effect of:
> 
> EraseBootDriveOnPowerUp: this option will perform an
> "erase" operation on the "boot" drive that is reported by the OS
> using the PEZIX-compliant frobnitz (2) function.  Valid values for
> this option are *foo*, *bar*, and *stickygumboots* These options are
> further explained in the following section...

Understood.  Obviously, the point of the "values" I chose was to
illustrate to the user (who rarely consults supplementary docs)
what the current choice "means".  For most settings in most
applications, I think you can come up with setting "names" and
"choices" that give the user a pretty good idea of how the
application will behave *with* those choices in place.  I don't
worry about the guy who doesn't even know how the application
is intended to work -- presumably, he won't be dicking around
"under the hood" with settings for an application he hasn't *tried*
to use, etc.

But, of course, users are users... :-/

Thx,
--don