Is there anything *enjoyable* about our development process?

[Christian Stimming]

Just to add my take on that whole thread as well:

Am Freitag, 14. Oktober 2005 19:53 schrieb Chris Shoemaker:
> 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.

Agreed on the main hypothesis, too. However, the described project means that 
the situation of the -Ofun perl6 compiler is not at all comparable to the 
gnucash project. Firstly, in the perl6 compiler project the developers are 
inherently also the users of the product. Secondly, in the compiler project 
the users are inherently also developers, or at least familiar to the way of 
how the developers will think. Both are definitly not the case in gnucash. 

In other words, the requirements and users' needs in the perl6 compiler are 
pretty much obvious to the developers. Not so in many aspects of gnucash. The 
fast feedback look that makes the perl6 compiler project so much -Ofun is 
simply not there in gnucash. We are happy enough when there is *any* feedback 
from real users -- feedback that we can understand and that we can use for 
code improvement, that is. Not to talk about the more difficult feedback loop 
in a GUI program as compared to a compiler, where you can specify test cases 
so much easier in the latter.

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

No, I don't agree with that assertion. The development process in gnucash 
needs to be different than a compiler's development process because the whole 
project is different.

And just to give a different voice here: I have soooooo much fun developing 
gnucash! My vision for gnucash has been and still is the "free manager for 
the personal finances, including the most modern online banking features, to 
make the private financial management as easy as possible". Of course that 
was limited to Germany, because only here we have the HBCI protocol which 
enables us to move *real* money from our very own source code. Every other 
day when I let gnucash connect to my bank, I think this is soooo cool. 

I had some success factors that made the HBCI parts especially fun for me to 
implement and maintain: The module structure in gnucash makes it possible 
that the HBCI stuff doesn't interfere with anyone who doesn't want to keep 
track of the HBCI library (now using aqbanking). The tasks of HBCI online 
banking consists of only a few relatively straightforward actions, which fit 
well (probably by coincidence) into the existing menu hooks. The engine has a 
clearly defined interface, where all the importing accessors and setters are 
clearly defined. So, yes: I have so much fun maintaining and improving the 
HBCI interface of gnucash, and I really enjoy this.

And for the ever-lasting Scheme discussion: Before the gentle reader 
formulates another refutation about Scheme in general, he/she should please 
spend 15 minutes to read some introduction e.g. on 
http://www.htdp.org/2003-09-26/Book/curriculum-Z-H-5.html (you can enter the 
Scheme expressions directly in "guile" as described e.g. here 
http://www.gnu.org/software/guile/docs/guile-ref/Running-Guile-Interactively.html ) 
15 Minutes. Really better spent than on yet another anti-whatever-Language 
flamewars.

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

Improvements are always good. A modern version control of course is better 
than the old cvs. Svn would make many different branches much more easier 
than CVS, although multiple branching would still work in CVS, iff people put 
up and do it. The question simply is: who does the transition work from cvs 
to e.g. svn? I can't; no time etc.

Christian