[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: RE: Tim Bray on "Which Technologies Matter?"

• To: 'Mike Champion' <mc@x...>, xml-dev@l...
• Subject: RE: RE: Tim Bray on "Which Technologies Matter?"
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Mon, 18 Mar 2002 13:18:01 -0600

No flames here.  The "dare to do less" thing 
is a pretty good idea when responding to an 
RFP even when it costs you the gig.

The only problem is that nothing simple stays that 
way if it is actively used.  The more actively it 
is used by more parties, the worse the problem. I 
remember when I could still work on my car or truck.  
Anyone want to return to 40hp VW bugs?

Markup started out simple.  That was the point 
even in the 60s.

Happy flying.  Get to the airport early.

len

From: Mike Champion [mailto:mc@x...]

3/18/2002 1:35:53 PM, "Stan" <StanD@s...> wrote:

>How does one know when a given technology reaches the 80/20 point other
>than by its success in the marketplace? Maybe the 80/20 point is a good
>predictor of success, but the whole concept of 80/20 is too slippery for
>me to grasp. Could someone tell me how does one design something to hit
>the 80/20 point?

Hmm, I feel a decision tree discussion coming on.  Too bad I'm about to be incommunicado
for the rest of the week ... I'm sure Len will flame my arguments to 
a crisp in my absence <grin>

I'd say:

- Occam's razor: choose the design with the fewer components, all things being equal

- It's an attitude, not a specific design criterion "Dare to do less!"
  Tim Bray had a nice message on the TAG mailing list around the first of the year,
  http://lists.w3.org/Archives/Public/www-tag/2002Jan/0000.html
     But I think the Web and the W3C would both have
     been well-served if at a couple of points in recent years
     some voice could have spoken ex cathedra saying "This is
     too complicated.  Go back and throw some of it away or find
     another way to fix the problem." 

- Take the "Extreme Programming" approach and do the simplest thing that could
  possibly work, then figure out what you learned from the experience, refactor,
  and do it again.  Iterate until your "paying customers" are solving real problems
  with your technology better than they do with the alternatives.

• Prev by Date: RE: Tim Bray on "Which Technologies Matter?"
• Next by Date: Why One Degree of Separation Matters
• Previous by thread: RE: Tim Bray on "Which Technologies Matter?"
• Next by thread: RE: SV: Tim Bray on "Which Technologies Matter?"
• Index(es):
  • Date
  • Thread