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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
