RE: Harvesting experience as well as architectures

 

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Sunday, July 14, 2002 7:24 PM
To: 'Champion, Mike'; www-ws-arch@w3.org
Subject: RE: Harvesting experience as well as architectures



 

The problem is that I don't think that one size fits all. So even if we want
to go for the 80/20 rule (which I agree is a good idea) which 80% do we go
for as one person's nice to have is another's must have ... thoughts? 

That's a very good point.  There's clearly an art to finding the right
balance between having enough features to be useful and being simple enough
to be understood.  http://www.4hb.com/08jcparetoprinciple.html
<http://www.4hb.com/08jcparetoprinciple.html>  and
http://library.shu.edu/HafnerAW/awh-th-math-pareto.htm
<http://library.shu.edu/HafnerAW/awh-th-math-pareto.htm>  (or Google for
"pareto principle" for a lot more) describe the idea here in more detail.

I think the point of the 80/20 rule for us is to seek the set of features
that give the most power in return for the least cost in complexity.  Or to
put it differently, to add those features that can be easily accomodated by
minor tweaks to the rest of the architecture, and to resist those that
require major new components to implement.  Of course, it's just a
heuristic: there's no guarantee that one can even minimally satisfy everyone
without a lot of complexity.  Also, both SOAP and REST appear to be textbook
examples of the Pareto principle in practice, but there may not be a clean
way of combining them.  (I personally think that there is ...but that's
another discussion!).

So, we have to focus on the "must have" requirements of the greatest number
of participants, and we can add "nice to have" features that cleanly fit in
with the others with only minor tweaks to the architecture.  But when we
find ourselves spending most of our time for a few weeks debating the
relatively small details or relatively minor requirements, it's time (again
in Tim Bray's words) to determine the "least we can do and still declare
victory."

I think Tim's point about HTML "changing the world" even though it just has
one-way links with no metadata and no redirection is the kind of thing to
look for and look out for.  If we find that we have got the big issues
nailed down but are beating our heads against the wall to get consensus on
the small ones, then it's time to simply revise the requirements document,
or whatever else it takes to "declare victory."   This probably seems
overwhelmingly obvious, eh?  But my point in bringing this up is that it is
a sad truth that a number of standards efforts, within and outside of the
W3C, have gotten stuck on this kind of thing.