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

[Phillip J. Eby]

At 11:26 AM 9/6/2007 -1000, Brian Kirsch wrote:
>Well the discussion is based on Risk. Do we risk re-architecting for
>a long term goal at the potential expense of features,
>losing early adopters, and reaching the end of funding.

Well, if it's based on risk, I'd say something more like, do we risk 
having all our years of work fade into obscurity as it rapidly 
succumbs to a lack of maintenance.  :)

To me, that looms as a bigger risk.  I spent about 15 years on an 
application suite that vanished off the net shortly thereafter, and 7 
years on an enterprise system that's still running 3 years later.  I 
imagine you can guess which one I feel better about.  :)

That having been said, I don't have as much invested in Chandler as I 
did in either of those projects.  The first I was a minority 
shareholder in the company, and for the second I was creator/auteur 
and project manager.  On Chandler I'm just "hired help", so it's not 
my money and it's not my vision.  But I'd *still* like to see it 
around 5 years from now, and from that perspective I don't see the 
end-of-'08 functional requirements being nearly as important as 
non-functional requirements like performance and maintainability.


>Now on to what I would like to see by the end of 2008.
>
>Month View, Contacts, Printing, Rich text editing, Localizations,
>Cleaner UI experience,
>Better UI menu verbiage and tool tips, enhanced detail view
>experience, better Triage
>capabilities, and incorporation of additional feedback from the
>community.
>
>Can we accomplish these and do a major re-architect by the end of 2008?

The only honest answer is: "it depends".  It depends on what specific 
features are meant under each of those things.  How many 
localizations?  Printing of what, how?  (E.g., do we just want to 
generate PDFs using one of the Python reporting libraries?)

What features for contacts?  What's an "enhanced detail view 
experience"?  Depending on the specific definitions of those 
features, the answer ranges from "sure, why not!" to "are you 
kidding?"  But of course that's true whether we refactor or not -- 
which is why I don't think it's a particularly fruitful path for 
evaluating the decision.

It's important to recognize, by the way, that refactoring doesn't 
mean new features stop being developed -- it just means they can't be 
*shipped* until the refactoring is complete.  For example, there is 
no reason to wait until the entire app is ported to start work on 
implementing contacts, unless there are other pieces that have to be 
there first.

Again though, I want to back up and say, I'm not *advocating* this 
approach.  If folks suddenly turn around and start being enthusiastic 
about it, I'm going to be the first one to start chiming in about the 
detailed risks and issues that *I'm* aware of.  I explicitly *don't* 
want us to take this path if the organization isn't 100% committed to 
it, because if we take this path we absolutely won't be able to 
afford any time bickering about it along the way.

But I'm nonetheless speaking of the merits so that if the other path 
is taken, it will not be taken blindly.  No matter which choice is 
made, we should know what we're giving up by *not* taking the other 
one, and be okay with that, as the price of what we want most.