Is there anything *enjoyable* about our development process?

[Chris Shoemaker]

On Fri, Oct 14, 2005 at 07:56:36PM +0100, Neil Williams wrote:
> On Friday 14 October 2005 6:53 pm, Chris Shoemaker wrote:
> > I recently came across (via /.) a brief 1-page article titled "-Ofun":
> > http://www.oreillynet.com/pub/wlg/7996. I agree with the author's
> > thesis, which is that optimizing a project's development process for
> > the pleasure of developers leads to all sorts of good things.
> 
> Very interesting article - each objection is countered and he makes a good 
> case. Personally, I've found the "fun" being drained out of my gnucash 
> development because of the pressure to get G2 out. There are too few 
> developers and gnucash development itself, IMHO, is currently not much fun at 
> all.

I feel the same way, but I don't think it's because of any pressure
related to G2.  I think it's more just the whole painfulness of the
whole process.  I'm trying to pin down exactly what that includes.


> 
> Nobody wants all this again with Gnome3. Something needs to change. I fear the 
> loss of a "community" feel to gnucash.

User community or developer community?  Because I'm not sure I'd call
this a "developer community".  More like a small group of over-worked,
over-tired, long-suffering, obstinately-determined coders desperate to
have a decade's-worth of code not rot into oblivion.  I don't
know... an image of a pack of drowning rats just popped into my head.
:)

> 
> During my short time in gnucash, I've had contact with two possible new 
> developers who have decided not to pursue their interest. Various reasons are 
> given but the sense is that they have simply found something better to do 
> with their time. Something that is more fun, more involving and provides more 
> positive feedback may help to retain at least some of these people.
> 
> How many of us have similar experience?

Well, it's not for the easily depressed, but if you read -devel
archives, you could probably come across ~50 of those over the past 5
years. :(

> 
> > As applied to GnuCash, I would make a stronger assertion, though.  I
> > believe that GnuCash's continued progress and relavence, absolutely
> > *depends* on a drastic revamping of the development process.
> 
> I agree.
> 
> What about this bit:
> "Continuously push the team to sketch out ideas in code, committing quick and 
> dirty protypes that can be refactored as they grow."
> 
> Quick and dirty prototypes may well break the overall build - I saw little in 
> the article about whether this was a problem or whether such a principle is 
> outdated by the move to a different version control method. 

Not outdated.  In fact I think maybe this technique almost *requires*
a version control with quick and easy branching.


> The only 
> reference is v.brief:
> 
> "Having this safety net allows the project to run full-bore without 
> time-wasting process getting in the way, and without undue worry that code 
> quality will suffer."
> 
> The basis of the article is experience with the Perl6 compiler - a large and 
> complex project like that should mean that the benefits can be transferred to 
> our complex gnucash build.
> 
> However, the devil may well be in the detail. By definition, people interested 
> in a Perl6 compiler will tend to be other developers. Although gnucash-users 
> generates lots of wishlists and ideas, there aren't that many developers 
> coming our way. Our userbase is fundamentally different from the example in 
> the article.

True, but the claim is that the project's success was due to the
pleasant development process, not the project's content.  I think it's
a reasonable claim.

> 
> So with limited numbers of possible new developers available, we aren't doing 
> a good job of encouraging their contribution. That needs to change.

I agree, but I would say it differently.  Let the pleasure of
development be its own encouragement.  We just need to remove the
sources of *dis*couragement, i.e. the pain currently associated with
development.

> 
> > Fortunately, I don't think this will require much innovation.  We can
> > simply emulate the many projects that are thriving, attracting new
> > developers, etc.  However, I do think it will require a lot of
> > initiative on our part.
> >
> > Does anyone agree?
> 
> Yes.
> 
> > If so, I'd like to start discussing what concrete things we can do to
> > improve the whole developement experience, considering ideas from the
> > article and elsewhere.
> >
> > E.g. Would a modern version-control system improve the development
> > experience?  (It seems like several of the other recommedations in the
> > article depend on it.)
> 
> By modern do you mean SVN or something more like GnuARCH? I've had a nasty 
> experience with gnuarch but I'm willing to give it another try. The problem 
> was that until the arch setup is well understood, it's a steep curve and the 
> confusion is immense. Simple failings in the "checkout" and "login" type 
> procedures are not handled gracefully by the current front ends - the errors 
> are misleading and unhelpful. The very fact that there are two front-ends 
> with different command sets is hard enough.

I don't know what a good choice of version control would be.  But I do
know that if the version control is painful to use/learn, it pretty
much doesn't support the goal of reducing pain.  That said, I'm pretty
close to desperate enough to try anything that looks promising.

-chris