Is there anything *enjoyable* about our development process?

[Chris Shoemaker]

On Sat, Oct 15, 2005 at 12:13:07AM +0100, Neil Williams wrote:
> On Friday 14 October 2005 8:54 pm, Derek Atkins wrote:
> > Quoting Martin Preuss <aquamaniac at gmx.de>:
> > > What frightens me most is scheme...
> 
< snipped griping about scheme... :) >

1) Scheme is far easier than it looks, and well worth learning.
2) Yes, it's off-putting in GC because it used, IMO, in an inappropriate way.
3) It's pretty high on the (long) list of things to fix, and with good reason.

But I'm more interested in the stuff you wrote afterward...

> I've been recommended to learn scheme so many times within gnucash but NEVER 
> outside it. Why should new developers be treated in that way? I've mentioned 
> this before, we are not flushed with offers of new developers, we cannot 
> afford to make gnucash *less* appealing than A.N.Other project. People will 
> gravitate to one of two projects:
> 
> A) The one they enjoy working within the most, or
> B) The one they REALLY need to fix for some personal itch.
> 
> Developers who join for reason B will be pre-occupied with their own needs, 
> reticent about taking on things like scheme (because they just want to 
> scratch their itch) and prone to leaving immediately their need is met.
> 
> The original article that started this thread was all about making gnucash 
> appealing for reason A.

Yes, that's right.

> 
> I enjoy working within QOF - that is my emphasis and all my work in QOF is for 
> reason A. 
> 
> Unfortunately, I am working within gnucash more for reason B than reason A. I 
> sincerely hope that this will change and I want to encourage a climate that 
> tips the scales in favour of A.
> 
> Learning scheme just to get under the skin of gnucash is simply too much of a 
> barrier to many prospective developers. I guess that may be why it's been so 
> hard for me and why I've had so many problems getting under the skin of 
> gnucash. Those problems have inevitably caused problems to other members of 
> the team.
> 
> Scheme is another of the hidden barriers in gnucash. Others could be:
> 
> 1. Hard to follow code layout - src/engine in particular has caused lots of 
> confusion on this list when trying to relate to QOF. CVS is the main problem 
> here, preventing file system re-organisation. (I like CVS but I recognise 
> it's problems too).
> 
> 2. Confused function naming conventions and file naming conventions. (Again, 
> filename problems are related to CVS - function names are just historical and 
> a lack of time to change them).

I agree w/ 1 & 2, but think of them as the same category of problem.

> 
> 3. Lack of developers (catch 22 - the fewer active developers, the less time 
> is available to help prospective new developers).

I *strongly* believe we need to stop thinking of this as the problem,
and start seeing this as just the natural consequence (or symptom) of
the *real* problem(s).  <analogy> I think we're kind of like a guy
who's broke and stranded, trying to get home.  We're trying to buy
some gasoline but not realizing that the real problem is that we have
no car; and if we get a car, it might just have some gas
already. </analogy>

> 
> 4. This isn't gnucash's fault but such a large project is a *difficult* one to 
> take on. We can't reduce the codebase but I feel we all need to make it 
> easier for new developers to get "under the hood". One BIG problem for me has 
> not been "code" but *code management*. Each developer here has their own 
> scripts and tools, procedures and routines for updating from CVS, test 
> builds, separate test trees, favourite editors, tab conventions, etc.etc. 

You're right, this is HUGE.  There's enough pain in the codebase
itself, but much of the pain is in code management.  We *have* to fix
this somehow.


> Some of this DOES need to be formalised somewhere. I've lost count of the 
> number of commits where one of the other developers has rounded on me for 
> some problem that I had not anticipated. We can't all telepathically know how 
> to manage the code and the commits. Sometimes I do wonder if it is worth the 
> (seemingly inevitable) hassle. I should not dread making a commit, or have to 
> set aside most of the following day to answer queries and explain why I did 
> certain things. 

Oh man!  This is *exactly* what I'm talking about.  Any enviroment
that makes you dread and delay committing is pretty much the exact
polar opposite of the goal set forth in the article.  I have to say, I
think *this* is the root symptom.  If we can fix this, everything else
will folow.

-chris