[
Lists Home |
Date Index |
Thread Index
]
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@xegesis.org]
3/18/2002 1:35:53 PM, "Stan" <StanD@standyck.com> 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.
|
