Strategy

[Hendrik Boom]

On Sat, 03 Dec 2011 16:40:07 -0500, Donald Allen wrote:

> I've been watching with interest the messages flying by from various
> people that confirm the impression (from just trying to build it) that
> Gnucash has become a gigantic hairball. John Ralls has been saying a
> number of things that sound smart (I'll tell you later where to send the
> check, John) about design errors, problems in the data model, etc., and
> has embarked upon a re-design. Christian has taken a similar step back
> with Cutecash. Then there's the whole issue of the use of Scheme. Much
> as I love the elegance of the language, I doubt that its use is
> appropriate here, for all the reasons that we've discussed ad nauseum.
> 
> So I'd like to suggest that perhaps none of the proposed ways-forward
> are radical enough. I have little to no knowledge of Gnucash internals.
> The only thing I know about the quality of the design and the code is
> what I read from the people who are currently doing the real work. But I
> do have many, many years of experience working and managing projects of
> similar and greater complexity, and there are times when you just have
> to cut your losses. Gnucash has been around for a long time, and its
> life-span covers the development of a lot of tools. If you were going to
> start with a blank sheet of paper today, I doubt very much whether you
> would do a lot of the system as it is today. The big question is, when
> is it worth it to cut your losses and start over?
> 
> I don't know that Gnucash is at that point, but I'm suggesting that you
> give this question very careful consideration, before doing something
> incremental. 

Rewriting is a normal process in the design and implementation of quality 
software.  In fact, I consider it essential in maintaining clarity and 
making reliability possible.  But most rewriting is incremental in a well-
modularized program.  And rewriting that makes a program more modular is 
often the best kind.

In a large program, I often spend half my time rewriting existing code 
with no change in program behaviour.  It's essential to pave the way for 
later substantive changes.

The truth is also that it's very difficult to know how a program should 
be organized from the start.  Only if you've written a number of similar 
programs before do you have much of a chance of guessing right ab initio.  
So rewriting and reorganization had better be part of ones' strategy all 
along.

> Keep in mind that if you did start over, the current system
> wouldn't be a total loss. I'm sure there is a lot of value in things
> like accounting rules that it enforces, and other knowledge embedded in
> the code. Some of it might be salvageable by lifting parts of the code
> itself, or at least doing translations. Other cases might involve just
> transferring knowledge of how to do things and how not to do things. But
> I say don't throw good money *possibly* (not definitely) after bad
> without at least considering whether it's time for Gnucash II.

Seriously, I've thought of it before deciding to join this project in any 
role but kibitzer.  There's lots of ways I'd like to rewrite it all from  
scratch (redoing it all in Modula 3, for example).  But in my opinion it 
provides me more return for effort just participating in what's here 
already.

-- hendrik