[Chandler-dev] Framing discussion about desktop architecture

[D John Anderson]

I can relate to this argument. However, from my vantage point I see  
it a little differently.

For the parts of the code I understand well (or better yet, the code  
I wrote) I'm very comfortable working on it. Sure, I wouldn't have  
done CPIA if had known the goals it was designed to solve would  
eventually be dropped, and yes, I'm all for improving it.

For the code I didn't write or don't understand very well, e.g. the  
repository, I find it frustrating to work on. And even though the  
repository API is documented, I still find it difficult to work on.  
I'm sure if I were in Andi's shoes I'd feel exactly the opposite. The  
same goes for wxWidgets, which is documented and has lots of people  
working on it.

Sometimes when we've changed the architecture in the past -- for  
example changing the way we do stamping -- I've found the new code  
more difficult to work on and understand than the old code. I suspect  
the reason might have more to do with my lack of understanding than  
an advantage/disadvantage of a particular architecture.

Having worked on so many different software projects over the years,  
some of which I designed from the ground up and others that I started  
working on late in their life, I can relate to Grant's frustration  
trying master a pre-existing large code base. All of the successful  
projects I've ever worked on eventually fall prey to complexity .  
Sometimes that kills them. Sometimes the attempted rewrite to improve  
complexity kills them. More often than not, the ones that live the  
longest do the best job at balancing re-architecture with new features.

So, I'm probably most comfortable with a middle ground. Doing a some  
re-architecture while focusing on improvements that make customers  
happy. I also think that we could also benefit by using some of our  
time working on tests suites to test various components, e.g. test  
the repository, in isolation of the rest of Chandler.

John

On Sep 12, 2007, at 2:14 PM, Grant Baillie wrote:

> Hi, Jeffrey
>
> I meant to reply to your email early, sorry.
>
> Personally, I've been considerably frustrated by how hard it is to  
> write code on our project. I don't work so much at the CPIA layer,  
> but below that the "brittle" and largely  undocumented API problem  
> really impacts my productivity, whether it's because it makes  
> making changes more difficult, or whether it's because I'm often  
> having to be distracted to revisit old changes that have turned out  
> to have had surprising and negative consequences.
>
> I can elucidate exactly which brittleness I find difficult, but  
> this is the high-level picture. I feel strongly enough about all  
> this that I'm quite sure I would be pretty unhappy chipping away at  
> the code base the same way that I have for the past 12 months.
>
> --Grant
>
> On 6 Sep, 2007, at 17:28, Jeffrey Harris wrote:
>
>>> Second guessing past decisions is unlikely to be fruitful, I'm not
>>> interested in recriminations, but I'm not sure we're all on the same
>>> page about whether the existing architecture is problematic.  Is  
>>> there
>>> frustration?  How bad is that frustration?  Where is it focused?
>>
>> So, personally, the CPIA layer, which I think is persisting lots of
>> things that seem to me to be UI details, is frustrating to work with.
>> I'm also worried about the notification/observer universe, but  
>> (perhaps
>> because I understand it better) I'm not particularly frustrated with
>> this (except when I'm trying to improve performance).
>>
>> If I could, I'd back up to 2005 and model recurring events as one  
>> item,
>> not many.  The current model is frustrating to work with, but I'm not
>> sure how feasible it would be to change this now, so I'm not thinking
>> we'll change recurrence any time soon.
>>
>> I've been wondering if it would work to have a few developers work on
>> replacing CPIA, without making radical changes to
>> collections/notifications (for now).  In this scenario I envisage  
>> most
>> developers focusing on incremental bug fixes and small features  
>> that new
>> users clamor for.
>>
>> Sincerely,
>> Jeffrey
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> 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