Hello,
I would like to re-iterate Philippe's comments regarding the death
threshold.
As the key to sustainability is adoption, any large refactoring that
takes away
resources from improving the user level features of the product is
concerning.
Chandler has a history of re-architecting components after major
milestone
releases. This does slow down user visible feature improvements and
has resulted in key components
not being implemented such as Contacts and a Rich Text UI editor
because developer resources
were focused else where.
Now that we have reached Preview, it is my opinion that the focus should
be squarely on improving and augmenting the user level feature set
based on adopter feedback. Given that the current funding window is
closing it seems the best use of developer resources.
It goes with out saying that release dates are never fixed and that
development always takes longer then expected. Preview was
targeted for March but is shipping in September. Given this fact,
it is high risk to tackle any major architecture changes at this point.
I certainly agree that our testing framework is not optimal at the
moment and
to some extent there must be improvement.
There is also much room to simplify the UI interaction model to increase
performance and reduce complexity. We also have way to many
observers and notifications being fired. These features are great in
terms
of decoupling architectural components but it comes at a heavy
performance
price. Mail download is certainly one of those observer cases.
There are a number of callbacks being fired for each piece of
mail that is downloaded at the expense of performance.
One advantage of the proposal to not use UI transparent persistence
is localization. It would eliminate the current issue of localized UI
titles
being cached in the Repository. With this barrier removed runtime
changes
to locale and translation strings will be correctly rendered with out
any additions
to the Schema.
In closing, this is an important discussion and one that is very
appropriate
now that Preview is almost out the door.
-Brian
On Sep 5, 2007, at 7:47 PM, Philippe Bossut wrote:
Hi,
Phillip J. Eby wrote:
To a certain extent, these approaches *appear* riskier because
there is a definite up-front cost, and the human brain is biased
towards options that lead to a sure short-term gain and a possible
later loss, over options with a sure up-front cost, for a possible
later gain -- even if the two options are mathematically
indistinguishable in terms of net gain or loss!
Well, it's worth knowing then which mathematical function you're
trying to optimize: is it long term life of the project? is it how
useful it is to users? Note that in all scenarios, if the function
(a) crosses the death threshold (no more funding whatsoever) in the
process, it doesn't really matter if, asymptotically (a) and (b)
are indistinguishable... So even if the long term is important,
trying not to die on the way is important too (remind me of this
interesting reading: http://paulgraham.com/die.html).
So it tends to come down to the question of what kind of delays
we'd prefer: relatively predictable up-front delays, or release-
time delays of unpredictable duration?
I like predictable, the question is: how long? and how much effort?
If the issue is adequate test coverage (and having a test-driven
development culture), then I think we *can* have a considerably
more predictable release cycle. In a test-driven model, the
architecture is forced to be modular (and acyclic!) in ways that
we currently aren't.
Ultimately, this is a "bet the farm" decision, and all choices are
equally risky in the sense that the wrong one will sink the
project. The major advantage of option #1 is that its failure
mode doesn't carry any *personal* risk to the individuals involved.
That is, in the "nobody got fired for buying IBM" sense, it makes
sense for *everybody* involved (me included) to CYA by
recommending option #1. If it fails, nobody can point a finger at
any of us -- especially since the most likely form of failure is
just that the project just fades slowly into obscurity.
To choose option #2 or #3 is to open one's self to possible
ridicule; every setback, however minor, may be used by the
ignorant as an excuse to attack the decision.
No one will argue and say that a test-driven culture is a bad thing
or that adequate test coverage is preposterous. The element of
decision you're keeping out of your reasoning is time and amount of
efforts. This is however the yardstick that'll get the project
funded or not eventually. I can only guess how much work what
you're proposing (i.e. rewrite the whole architecture so to ensure
full testability) will cost. One thing though gets me worry: the
way you frame things, it seems that you assume that embarking on #2
or #3 will basically stall the current project (Chandler Desktop
0.7.x), meaning consuming all resources and leaving existing would
be users in the cold, or, IOW, we may as well renounce recruiting
users with what we have. Do I decode you correctly? If it is,
frankly, I think that those options are non-starters.
On the other hand, I can imagine that doing #2 or #3 doesn't mean
we have to stall 0.7.x though it will certainly split the team.
Doing so however depends heavily on the cost of #2 or #3.
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
