Beyond 1.5

John and I were exchanging mails with some of the other developers on the project when one thing led to another and suddenly we were discussing how to proceed beyond 1.5, how to get the much desired old code eliminated and how to get the financial rewrite done. I'm bringing it to this list because I think the subject concerns the community at large - not just a few of the developers.

Quoted text below from John Locke's mail.

[ .. snip .. ] we've been dancing around old code for a long, long time -- are we ever going to clean it up incrementally?

While I've been hesitant to answer that question in the past (but always believed in it), I can answer with a firm "Yes!" these days. The plan is as follows, as far as I'm concerned:

* Isolate old code so it's completely clear to everybody which code we want to remain untouched

* Create Dojo widgets to gradually replace functionality in old code with a well defined web API and a client UI

* Create web services to support the Dojo widgets (and other remote access, of course)

As a matter of proof that this is going to work to phase out old code: we already have a functionality in 1.5 which follows exactly this approach and has led to deprecation of a significant complexity in old code: the parts selector in the invoice, order, quotation, customer price matrix and parts (bom listing) screens has been replaced by a single Dojo widget.

I'm thinking we're better off at this point with a rewrite -- or at least for the time being, a solid enough plan in place so that the new stuff we're creating will port straight into a 2.0 when the time comes.

Well, given that we have found a way forward now to get rid of the old code, I'm thinking we should proceed on that route for a while -- it might just be the key we needed.

It's also the main driver behind my efforts to start talking about the document state diagram and the requirements for a web service framework: it's *the* driver to be able to continue on this route and a major enabler of a lot of other efforts.

If the core issue keeping us from tackling the financial rewrite and heading for 2.0 is the database schema, I think we should drill into that and make that solid, as soon as we possibly can. [ .. snip .. ]

Agreed. My definition of "as soon as we possibly can" would be: once we have phased out the old code. Seriously, there's a lot of dependency in old code on the current schema, without the sorely needed separation of concerns. Rewriting the database schema now would require editing a lot of old code -- something we really don't want to do. As soon as we have removed our dependency on old code, it'll become a lot easier to rewrite the stored procedures. It'll also become possible to rewrite without breaking it *all*, because we'll have many, many more tests in place to validate consistency and correct operation.

I can definitely see that it may take us years to get there, and we may have several more 1.x releases -- but clearly there's a need here, and the longer we wait to start on it, the longer it will take to get it working...

While in general I would agree, I'm also seeing a major uptake in development activity over the past 12 months. We have put in place a number of enablers to help people join the project in the same period. To me, it seems the strategy is working and while in the past development may have been slow and painful, it's now "just" painful, but no longer slow.

When we have more testing in place (BDD or otherwise), development won't even be painful anymore.

So... what's wrong with the financial schema

A *very* relevant question which I think should be answered in the short term so we can make sure that all changes move in the right direction. I however, don't have the answer.

@Chris, do you have mails, notes, <whatever document> which lists all or part of the problem(s).

(Ok, in all fairness, I know about:

- Journals should not run across dates

- payments should be journals, not lines on an AP item

- journals should be referenced from 'transactions' or 'gl', not from ar/ap
)

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.