[Chandler-dev] What is next for Chandler desktop?

[Philippe Bossut]

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