Is there anything *enjoyable* about our development process?

[Chris Shoemaker]

On Sat, Oct 15, 2005 at 11:52:15AM -0400, Josh Sled wrote:
> On Fri, 2005-10-14 at 21:05 -0400, Chris Shoemaker wrote: 
> > > 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.
> 
> I don't think people actually *do* have wildly different ways of doing
> these things.  Certainly there's a natural variation in the OS-level
> tools and enviornments, but when it comes to how most developers
> actually deal with the source, I think it's generally the same.

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.

> 
> Apparently the coding-standards document went away, and finding it in
> CVS reveals it didn't have a whole lot of info anyways.  It's pretty
> obvious from most of the code, but perhaps it's useful to get tab-size
> and brace conventions agreed to?
> 
> 
> > > 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.
> 
> Developers *shouldn't* commit code that breaks formatting conventions,
> arbitrarily changes existing conventions, has no prior agreement, does
> things wildly differently from how anyone else would do it, and needs to
> be defended after the fact.  They generally shouldn't commit code that
> breaks other people's environments without being very careful, first.
> They *should* delay those commits until the commits are ready.  That's
> true regardless of how decentralized the build system is, or how widely
> the commit-bit is cast, or how much fun is the goal.

I have to say, I coundn't disagree more.  A year ago, I probably would
have agreed, and 5 years ago, we would have been right, but not today.

This whole model is predicated on the assumption that code breakage
is the worst evil.  This was reasonable when recovering from code
breakage was far more painful than preventing it.  But the equations
have changed, both the costs and the relative benefits.  Modern
version control has *greatly* reduced the cost of code breakage.
Furthermore, GnuCash is at *far* greater risk of rotting than it is of
being terminally broken.

So... Developers *SHOULD* commit code that breaks formatting conventions,
arbitrarily changes existing conventions, has no prior agreement, does
things wildly differently from how anyone else would do it, and needs to
be defended after the fact.

I know this sounds wrong given our experience, but I think that more
recent and broad experience, plus sound reasoning based on the
psychology of software development gives evidence that it is true.
 
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.

Even if you don't buy all this, (and I hope you do), the strongest
point remains: "What's the alternative?"  A: Not sharing code, because
it's not conventional, non-controversial, and "safe".  Or because it's
too difficult to bring your code into that state.

Which one is better for Gnucash?

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.

To be fair, I've seen both models work.  But I've never seen 1) work
well for a project larger than a few dozen files, and I've seen 2)
work spectacularly well for huge projects.  I think Gnucash needs 2).

-chris