-------- Original Message --------
Subject: Re: Design Decisions
Date: Thu, 28 Aug 2003 16:18:42 +0100
From: Charles Goodwin <[EMAIL PROTECTED]>
Organization: XWT Foundation
To: Linas Vepstas <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
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
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
