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

[Phillip J. Eby]

At 02:05 PM 9/5/2007 -0700, Katie Capps Parlante wrote:
>Phillip Eby and Grant have been exploring some options (at my request),
>I'll let them introduce that work.

Broadly speaking, there are three options regarding the architecture:

1. Start with the current architecture and evolve it in-place
2. Define a new architecture in terms of "off-the-shelf" Python components
3. Develop an architecture specifically to suit Chandler's current goals

Each of these approaches has trade-offs.  #1 is heavily burdened by 
inertia in the long run, and has a high risk of not being able to 
meet future goals, but is extremely attractive (even addictive) in 
the short run due to the "high" of being able to get more features 
quickly, at the cost of later "hangovers" at release time.

That doesn't mean it's necessarily the wrong choice.  It's certainly 
a valid (if risky) choice to leave things as they are, and say, 
"we'll fix it when (if) we have funding".

The other two approaches carry a significant up-front cost: "porting" 
existing code to a new architecture.  But the immediate trade-off is 
that every bit of code ported can be verified as covered by automated 
tests, and the other issues can be resolved.

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!

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?

This might seem like rigging the question -- after all, it's not 
possible to 100% rule out release-time problems from a new architecture.

Or is it?

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.

For that reason, I do not suggest that we take option #2 or #3 unless 
there is a 100% commitment to a test-driven culture from everyone 
involved.  Without that, we'll be taking all the risks of a port 
without gaining the benefit of a 100%-coverage, fully-vetted codebase.

But without that test coverage, Chandler as a project will be on life 
support.  It's not reasonable to expect that volunteer maintainers 
are going to step up and match the amount of build and QA 
infrastructure that OSAF currently has, to work around the current 
level of testability.

So, I think we need to be clear about what path we're choosing, and I 
think that detailed proposals are actually beside the point at the 
moment.  If we *want* a test-driven Chandler, we can have it.  (And 
we may not even have to give up that many features to get it!)

But we should answer that question first, and *then* worry about the 
how.  Otherwise, it's all too easy to delude ourselves into thinking 
that we're making the right choice because there weren't any viable 
proposals for anything else (because none of them will be *perfect*), 
thereby avoiding the tough choice of what it is we actually want, and why.