Re: [xml-dev] Extreme Schema-building and Query-writing (was Re: [xml-dev] (data) medium is the message)

[Eric Bohlman <ebohlman@earthlink.net>]

5/2/03 1:51:29 PM, Mike Champion <mc@xegesis.org> wrote:

>So, what's to be done?  I don't pretend to have solid experience, but 
>maybe the ideas of "Extreme Programming" have a place here: figure out 
>the minimum amount of structure you MUST assume to be productive, get 
>constant feedback from the users to see if you are part of the solution 
>or part of the problem, and be ready to re-do it when things change, as 
>they inevitably will.  Maybe ... focus on finding the appropriate level 
>of constraints (maybe on tag names) that remove more "noise" than 
>"signal", but don't obsess about finding just the right content mode for 
>all the elementsl; maybe use data types and validation where they really 
>matter (dates, money, measurement) but don't try to figure out universal 
>abstractions for things like addresses and phone numbers that vary 
>greatly and are going to be read by a human anyway; and think more about 
>extracting the information you need from the data people create than 
>trying to make people create data that fits your needs.

I think a lot of what you and Spolsky are saying is that developers need 
to restrain their 
seemingly-natural tendency (especially if they come from math backgrounds) 
to place excessive 
weight on the *completeness* of systems.  Completeness can be extremely 
important in theory, but 
that doesn't mean it's always all that important in practice.  I think 
many developers naturally 
prefer broad, general systems that can be bent, with sufficient effort, to 
nearly any task over 
narrow systems that are well-adapted to particular tasks but can't be used 
for anything else.  All 
other things being equal, that would be a rational preference, but the rub 
is that "with sufficient 
effort."  I'm reminded of a quote from Peter Brown in his (now-ancient) 
book _Macro Processors and 
Techniques for Portable Software_: "The higher you fly in a balloon, the 
more towns you can see, 
but the longer it takes to land in any of them."  And also of the 
observation that computer science 
and software development are two completely different fields (even though 
results from the former 
can inform the latter).  There's no *theoretical* reason why we shouldn't 
do all our software 
development at the level of Turing-machine tuples; there are many 
*practical* reasons not to.


-------- End of forwarded message --------