On Gnucash, G2, and Architecture (was Re: [Gnucash-changes] Eliminate a double free of memory.)

[Chris Shoemaker]

On Fri, Jun 03, 2005 at 04:31:03PM -0400, Derek Atkins wrote:
<snip> 
> Um, you clearly haven't read my posts over the last, oh, five years.
> I'm always the FIRST to stand up and list the things wrong with gnucash.
> David listed a few.  A few more on my list:
> 
>   - the half-assed modularization effort
>   - the poor distinction between shared library and loadable module
>   - the fact that gnucash is fragile in the face of "/usr/bin/guile"
>     changing versions
>   - too much logic in the UI
>   - too many "gpointer" apis without real runtime type checking
>     (it would be better to have compile-time type checking, but
>     that's even HARDER is C).
> 
> I *AM* an architecture purist, even if you haven't been able to
> notice.  On the other hand, I'm also a realist, and truly believe that
> "The Perfect is the enemy of The Good".  I'd much rather have
> something less than perfect but still "good enough" and get it out the
> door than not have anything (because I haven't reached that nirvana of
> "perfect").
> 
> I think David hit the nail on the head when he said that we need to
> get the g2 port out the door and there are many real issues now that
> need to be fixed, places where the code crashes or just plain doesn't
> work...  And THOSE are IMHO orders of magnitude more important to
> fix/replace/repair than replacing code that might not be
> architecturally pure but still happen to work just fine.
> 
> In an idea world with unlimited resources, sure, I'd LOVE to
> completely re-architect gnucash from the ground up.  I'd probably go
> with C++ and Qt as my building blocks, but that's just a side note.
> We don't live in an idea world, and we don't have unlimited resources.
> Therefore, we need to take the resources we have and apply them in the
> most beneficial way.
> 
> Which do you think is more beneficial to the project in the next six
> months:
> 
> a) Taking a piece of code that might be architecturally questionable
>    but doesn't crash, doesn't corrupt data, and doesn't cause any
>    visual problems and spend time to fix the architecture and rototill
>    the code to change how it works?
> 
>  or
> 
> b) Take some code that causes the program to crash, corrupts data, or
>    visually misbehaves and spend the time to fix those issues?

        I honestly don't know.  I know the question was rhetorical,
but I think the answer really depends on many factors.  IMO, having a
g2 port that works as well and 1.x, but is equally (un)maintainable is
only of _marginal_ benefit.  (And I'm not sure even 6 months will find
us there.)  IMO, 95% of the benefit of the g2 port is the potential
for improving maintainability.  ** That benefit is not realized by the
quickest fixes, but by the design fixes. **

        You and I really do have very different interests regarding
GC.  I realize that the next 6 months are very important to you.  I'm
much more concerned about where GC will be in 36 months than 6.  I
figure, in 6 months, 1.x will still be an option.  In 36 months, it
won't be, and neither will g2 if it develops at anywhere near the rate
it has in the past 24 months.  Call me alarmist if you want, but I
think GC is "on the brink."  Its survival is no gaurantee.  IMO, its
survival depends on architectural improvements far more than fixing
visual misbehavior or program crashes.  Why?  

** Because the universe of developers willing and able to fix program
crashes is determined by the architecture, but the (very small) universe
of developers willing and able to fix the architecture has almost
*nothing* to do with the program's usability. **

<snip>
> In the grand scheme of things (or at least the grand scheme of gnucash
> [no pun intended]) I don't think this is a heinous architectural flaw.
> I can certainly point out a half dozen or more significantly more
> heinous archictectural flaws in gnucash.

I would agree.

<snip> 
> Personally I'd rather see you work on fixing code that's actually
> broken (read: doesn't work, causes crashes, causes data corruption,
> etc.) than spending time re-architecting code that works, albeit in a
> weird way.  Do I think the current code is the best possible way it
> could be done?  Hell no!  Could it be done better?  Hell yea!
> 
> But honestly..  How does changing the CM/Gtk interaction help us
> release the g2 port any sooner?  Shouldn't we make getting the g2 port
> out the door our #1 concern?

I think that should be *somebody's* #1 concern.  But I also think, for
the reasons above, that if that's *everybody's* #1 concern, then in 12
months, GC will still have the equivalent of < 1 full-time developer,
and it will be obsoleted within another 18-24 months.

I think *somebody's* #1 concern should be making the architectural
changes that will attract more developers.  I know you're said that
you don't really care about attracting new developers, and that we
have a few really good devs now.  Nevertheless, IMO, attracting more
devs is essential to GC's survival.

I also recognize that my prioritization is a minority view, but I
don't think it's necessarily bad that different devs have different
priorities.

> 
> Assuming you answer "yes" to my final question (and I really hope you
> DO answer "yes")...  

Was that a qualified "yes"?  :)

> what do you feel are the steps necessary to get
> the g2 port "finished" and out the door?  What do YOU think is missing
> or still needs to be done before it's ready to package up and pass on
> to users?

I don't know.  As a user, the register misbehavior really bothers me.
As a dev, the register code insanity bothers me even more.  :)

-chris