avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject Under Promise, Over Deliver
Date Thu, 20 Jun 2002 13:19:04 GMT
In my experiences with computing, the company's motto that impressed me
the most was Be, Inc.  Jean Louis Gasse' (sp?) was a genious for
the mindset of "Under Promise, Over Deliver".  For a commercial company
it really hampers the marketing department, but for an OSS project it is
the only mindset to have.

There are some key obstacles that seem to be in our way of achieving
this goal:

1) Over design, under simplification
2) Big ego, small content

The big ego, small content has already been hammered on, so we will try
to keep the signal to noise ratio down.

So far the most productive thread we have had was the "Fresh
as I finally got what Stephen and Peter were pushing (although at first
it was just Stephen).  There is a lot to like in it.

Our biggest problem is Over Design, Under Simplification.  The job of a
*usable* framework is to enable things to be done that otherwise could
not be done.  Avalon 4 does this quite well.  There are some things that
does not sit well with me in the track we are on for A5.  They are

1) The container specification is becoming quite complex.  The
   is hoped to be made up for by a "ContainerKit", but if someone wanted
   to discard the container kit and create their own container from
   it is approaching the level of needing a company to finance the
   proposition.  This is not good.

2) We are pushing *more* of the burden of design, thread safety issues,
   etc. on the component developer.  This is a *bad* choice.  ColdFusion
   4 tried to automatically handle the locking of CF script variables,
   but did a poor job of it.  Their solution was to offload that
   responsibility to the page developers.  By CF 4.5, we had a product
   needed to be revamped to explicitly handle locking of variables.  We
   are making the same mistake regarding pooling of components.

3) If anything, we want to make it *easier* to use.  Even better we want
   to make it *easier* to use correctly.  While it is a design goal to
   encourage good practices and discourage bad practices, we can't all
   do that at the interface level.  People follow examples, good or bad.

Now documentation and examples are something we can do in A4.  However
is the type of examples that need to make sense.  We need to demonstrate
*why* something is bad (performance, maintenance, scalability, etc.),
how to correct it *easily*.  Something like the J2EE BluePrint document
would be best.  We need to demonstrate how certain designs just work
and aren't that much more difficult to do.

Some things are difficult to do.  Pooling components is a valid
You could have fewer instances of components than threads of execution
opposed to the more common case in Cocoon where there are multiple
instances per thread of execution).  However, removing the release()
has incredible consequences on existing code for only a little ease in
the container.

As Benjamin Franklin said, "They that give up essential liberty to
obtain a
little temporary safety deserve neither liberty nor safety."  While
it has more to do with patriotism than with development, it still

Unless we provide a fundamentally *better* approach that does not tax
users, the proposed approach is flawed.  It is like when England raised
taxes on American soil without giving them representation in parliament.
The Americans eventually revolted, casting all things English aside.  It
wasn't until much later that America and England could stand each other
enough to resume trade relations.

This is *not* what we want for Avalon.  Any freedom we remove *must*
be replaced with something better.

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message