Is there anything *enjoyable* about our development process?

[Neil Williams]

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.

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

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?

> 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. 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.

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

> 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.

e.g. a simple error in the config led to me checking out files with 
unintelligible paths like:
\{arch\}/++pristine-trees/unlocked/packages/packages--debian/packages\
--debian--0/pkg-qof-maintainers\@lists.alioth.debian.org--experimental/packages\
--debian--0--patch-2/\{arch\}/packages/packages--debian/packages\
--debian--0/pkg-qof-maintainers\@lists.alioth.debian.org--experimental/patch-log/base-0

(Yes, that is a single, real, subdirectory on my home system created by a bad 
arch implementation on a remote system - and it resulted from the simplest of 
errors in the config yet there was no clue about how to fix it.)

This debacle cost me two full days. We can ill afford to waste time like that.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20051014/1beeaeeb/attachment.bin