Is there anything *enjoyable* about our development process?

[Josh Sled]

On Sat, 2005-10-15 at 14:23 -0400, Chris Shoemaker wrote:
> I think you may have missed the essential point.  It's not the variety
> (or lack thereof) of code management techniques.  It's the
> burdensomeness of *code management* tasks.

I didn't miss the point, I've been complaining about the overhead of
this for a while myself.

Neil said that everyone does everything differently, and that that is a
problem.  I just don't think that everyone *does* do everything that
differently.  Now I'm curious as to specifics, though.


> Furthermore, GnuCash is at *far* greater risk of rotting than it is of
> being terminally broken.

Interesting, as my arguement is that it is currently rotting because of
terminal breakage. :)


> Once you remove (or sufficiently reduce) the pain of code-breakage
> imposed by ancient version control, then NOTHING BUT GOOD THINGS can
> come from all those actions.  Breaking of conventions leads to people
> better understanding the underlying motivations for the conventions,
> and sometimes, it leads to better conventions.  Sharing wild new ways
> of doing things leads to a greater appreciation of the tried-and-true,
> and sometimes, it leads to a new best way of doing something.
> Defending code or a method leads to better understanding of its
> strengths and weaknesses.  ALL of these outcomes have collateral and
> immediate BENEFIT.

No.  Not *nothing* but good things; there are drawbacks.

Let's seperate out "if we never try novel ways of doing things we never
grow and evolve our techniques", because I'm not talking about that.  I
think that's healthy and good, even if I don't think it should
necessarily germinate in a project like gnucash.  I'm not against whole
new features, wholesale replacements of existing features, or even
adopting paradigms like QOF, &c.

I'm talking about things on the small/medium side: replacing spaces with
tabs, gratiutously adding code in style B to a file that's 90% in style
A, committing code that only compiles in a narrow environment,
unfinished infrastructure changes, &c.  All I'm saying is that there
should be a negative feedback loop about that.  People should be
encouraged *not* to do it, even if the version control system makes it
easy to get out of those states.  People should strive for quality, not
whatever just works.  Breaking the build is still a waste of time and
resources, even if not as much as before.


> 1) A small handful of developers who know all the conventions, never
> break the single build, only do things everybody agrees on, and can't
> keep their project from being dropped by distros - and no one dares to
> join in.
> 
> or 
> 
> 2) Several handfuls of developers who have to regularly be corrected
> in their breaking of conventions, regularly share code that doesn't
> work and has to be fixed, do things that nobody agrees on, but there
> are casual developers dropping in all the time and code keeps flowing.

[It distracts from your argument to parallel gnucash's recent history in
(1), because that's not what we're talking about.  The "dropped by
distros" part is due specifically to a *lack* of development, not
chaotic development.  As well, a lot of the actual progress toward
getting the gnome2 port done has come from casual patches and external
contributors (and David Hampton). But below I'm going to assume that the
small set of developers is actively developing.]

Of *those* two options I'd rather have (1).  The goal is *not* to get as
many developers and/or commits as possible.  The goal is to produce
working software.  Lots of developers generally makes that more
possible, but not necessarily.  So if the options are a small number of
safe developers or a large number of commits that don't compile/are
buggy/don't work everywhere/&c, I guess I'd rather have (1).  But of
course I want a mix of (1) and (2).

I don't think allowing any random checkin from anyone *necessarily*
creates great software, nor do I think that rejecting a patch with
comments because it does something too-strangely *necessarily* doesn't
do that.  I think there's value in maintaining the internal consistency
of a large program by having rough consensus and direction, and that
means saying "no" sometimes.

I don't think it's as useful for someone to spend the time to develop
commit a bunch of code that the other developers disagree with
architecturally or design-wise, and thus have to spend more resources
either buttressing or exterminating, vs. discussion and concensus up
front.  Certainly prototypes can help discussion and thus concensus, but
that's different than commits without prior agreement and/or needing
defense.

I don't think it's as-useful for people to submit broken code (or to
break existing code) as it is to have something that works, but I also
don't have a problem with patches that aren't quite finished going in
the tree so that people can more easily collaborate on them.  I also
don't think GnuCash as a project would reject such as patch as a rule.

Having many different developers over time with varying styles and
desires is part of what got the project into its current state.  So, no,
I don't think that that is necessarily its salvation.


I still think the reason patches aren't coming in is not because people
can't submit patches, or because they can't do `cvs commit` ... it's
because the code is too complex, hard to understand, and it's a PITA to
develop the changes in the first place.


In any case, I think we're mostly in agreement about this, and I look
forward to making this a better project for ourselves and others to work
on. :)

...jsled
-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`