Design Decisions

Charles Goodwin charlie at xwt.org
Thu Aug 28 18:20:47 CDT 2003


Oops, accidentally didn't send it to the list.

-------- Original Message --------
Subject: Re: Design Decisions
Date: Thu, 28 Aug 2003 16:18:42 +0100
From: Charles Goodwin <charlie at xwt.org>
Organization: XWT Foundation
To: Linas Vepstas <linas at linas.org>
References: <3F4244D7.2030809 at xwt.org> 
<200308191254.28750.bock at step.polymtl.ca> 
<1061319285.30884.42.camel at mightymax.charlietech.com> 
<200308191521.49973.bock at step.polymtl.ca> 
<20030828150222.GA18024 at backlot.linas.org>

Linas Vepstas wrote:
>>>Perhaps I should say 'ruthless evolution' is a more accurate term.
> 
> There are many lessons to be learned here.  At least one is that 
> re-writing from scratch is often more difficult than assumed, and 
> takes much longer than anticipated.  Just look at Mozilla vs.
> Netscape!   It pays to migrate old code, rather than redesigning it.  
> At first, it seems a much more slow way to proceed, a much more 
> painful way.  But it only seems slower at the start.  Towards the 
> end, the 'old code' is ready to deploy, because its actually 
> bug-free (because it always worked, had never gotten broken along the
> way), even as the 'new rewrite' remains buggy and unfinished.

I wasn't saying 'start from square one'.

Ruthless Evolution... identify what your utopia is, then take the steps
necessary to reach it, no compromises.  Reuse old code where possible,
and modify it where possible, and rewrite where absolutely necessary to
reach your goal.

This can be easily broken down into steps, which you could use as point
releases.  Whilst each step might be a compromise (read: realistic,
reachable target) they should culminate in an uncompromising end result.

The problem here is that taking a long term stance is often
controversial.  Look at the original opposition to the direction Gnome2
has taken.  It was an uncompromising vision that Havoc and other leading
developers had.  And now (Gnome2.2, Gnome2.4) the results are coming
through and a lot of people are being forced to reconsider their
original reservations.

The GnuCash developers need to put together a vision for future versions
of the GnuCash codebase.  I don't see that vision anywhere.  You just
seem to be incrementally adding features and addressing issues from
release to release.  "We want this and that in the next release."
Forgive me if that is not a correct assertion of the GnuCash development
pattern.  But if it is, then that is not a maintainable roadmap for a
codebase the size of GnuCash.

The next major release appears to be a shift from Gnome1 to Gnome2
(GnuCash 2.0?).  Ideally, this should have been a simple glade creation.
  How come it is so non-trivial?  Is the GUI that tightly integrated
into the application logic?

Personally I think you should look at making GnuCash more client<>server
based, so you don't have the GUI migration issues you currently suffer
from.  But how would that fit into your roadmap?  It doesn't, because
you don't really have a roadmap - not in the sense that Gnome2, Mozilla
or even AbiWord has one.

And you might be surprised at how a vision, a detailed roadmap inspires
people to contribute.  If they know where the project is going then they
have more direction and incentive to get involved.

Nobody wants to get into a car with broken headlights.  Fix 'em. ;)

- Charlie





More information about the gnucash-devel mailing list