On Gnucash, G2, and Architecture

[Derek Atkins]

Chris,

Chris Shoemaker <c.shoemaker at cox.net> writes:

>> 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. **

See, I don't think it's of marginal benefit to get g2 into the hands
of the users even if it only works as well as 1.8.  Indeed, currently
the g2 port does NOT work as well as 1.8!  I think just getting it up
to 1.8's level is sufficient to make users happy and extend the life
of the project.

I don't know if 6 months will find us there.  If we keep rewriting
working code then it certainly wont.  But if we focus on actual bugs,
so we CAN bring g2 up to the 1.8 working level, then I think it's
possible to complete in 6 months.

We've got GoG working, that was a major issue.  Now we just need to
make sure all the dialogs work, all the signals are attached, etc.
Sure, it sounds like busywork, but we're at the _end_ of the dev cycle
here and that's always busywork.  Once we release we can open up to
major restructuring.  But now is not the time to do it.

>         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?  

Actually, I don't think you're behind alarmist enough!  I'm also
concerned about where gnucash will be in 36 months, but if we don't
get the g2 release out SOON I don't think there will even BE a gnucash
in 36 months.  Gnucash has already started dropping out of distros.
We've been out of slackware for years (I think 1.6 was packaged, but
I'm fairly sure 1.8 never was).  We got dropped from RHEL 3.  I think
we're in FC4 but I suspect we'll get dropped from FC5.  Debian has
considered dropping it.  Fink has considered dropping it...

Seriously, if we don't get g2 out the door _THIS YEAR_ I don't think
there will be a gnucash in 36 months for you to primp and preen.

Keep in mind that we also need a good 3 months after "feature freeze"
in order to stabilize the release.  At least that's how long it took
to get 1.8 out the door.  There was a good 3 months of bi-weekly
releases to get alpha tested, build tested, and into user's hands.  So
even if we think it'll be another 6 months of developer work to
"finish" g2, that means 9 months until 1.10 actually hits the streets.
We're already late; that puts us into March 2006!

> ** 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.

Then why spend time on it _now_?  I'm not saying not to spend time on
it.  I'm just saying that it shouldn't be a priority _now_.  Help us
get g2 out the door so we can ensure gnucash's survival.  _THEN_ feel
free to really start ripping away.

Have you ever worked in a ground-up startup?  I mean REALLY ground up?
Where it was you and one or two other guys trying to make the business
happen?  Where you've got $100,000 and you need to make that last
until you've got a product?  In that environment you can't waste time
rewriting working code to build something you don't need until
two-years down the road; you need to work on getting the product
shipped, which means hacking on the non-working code.  Rewrites can
wait until you get the product shipped and you get the next round of
funding.

This is where I feel gnucash is _right now_.  Sure, I am _thinking_
about where I want gnucash to be in 36 months..  But I'm worrying
about where gnucash will be in 6-12, because no g2 release in that
timeframe means no gnucash.

> 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.

Gnucash is a team effort, even if it's only loosely associated.  We
have to work together to get gnucash out the door.  We have to make
forward progress, not continually re-working everyone's steps.

> 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 care about attracting developers who can work within the gnucash
framework.  I don't care about major gnucash restructuring just to
attract new developers.  Restructuring and rearchitecting because it's
the right thing to do is certainly warranted... When the time is
right.

Right now is not that time.  I've even given up on my qif-importer
re-write because I think it's more important to finish the g2 port
than the finish the re-write.  Why?  What's there _works_.  Yes, there
are some bugs.  Yes, it's hard to maintain.  Yes, it NEEDS to be
re-written...  But it's more important to COMPLETE THE TASK and get g2
out the door.

Gnucash's survival is not hinged on whether the qif importer is
re-written, or if the gtk/cm interaction is architecturally "pure".
It's purely hinged on getting g2 released.

We _ARE_ that small startup, trying to get that product out the door
in order to get more funding.  (Well, there's no funding here, but the
analogy still holds if you equate time with money ;)

After 1.8 was released we had a lot of time on our hands to ponder
major changes.  QOF, for example, was a major rearchitecting of the
engine, and IMHO a fairly decent step forward.  But _now_ is not the
time to create a new QOF.  Now is the time to get g2 out the door.
Once g2 is released, once we have 1.10.0 in the hands of the people...
THEN will it be time for you to go off and create your masterpiece,
create the next QOF.

I applaud your effort to fix that.  I even encourage it, but not right
now.  I ask that you hold that energy until we get g2 out the door.  I
implore upon you to help us get g2 out the door; after g2 is released
I encourage you to run free and wild rebuilding whatever floats your
boat!

> 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.

I agree, but I think it's bad right now that devs aren't concerned
about getting g2 out the door.  At least it feels to me that you don't
care about getting g2 released.  Please tell me I'm wrong!  But it
sounds like you'd rather rebuild working code now than wait until
after g2 to re-work it.

>> 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.  :)

Oh, I agree..  I'd LOVE to see the register re-written, and lots of
other code fixed, cleaned up, or rearchitected.  But again, I think
that's an "after the first g2 release" task.  It's better to spend a
couple days to get what's there now working and get g2 out sooner,
than spend a month rewriting and push out the release.  If we do that
for every bug in the database we'll never finish.

The more we push out the release, the closer we are to being
irrelevant.

> -chris

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available