Evaluation of codebases and what parts to rewrite (was Re: shared API for double-entry accounting, treating it as a 'math' library) Conservancy contractor.)

Bradley M. Kuhn bkuhn at sfconservancy.org
Thu Nov 14 13:34:14 EST 2013


Tim Schofield wrote:
> make sure you do the arithmetic as integers rather than floating point.
> Using floating point is a common mistake, which can end up with an out of
> balance TB.

Indeed, I'm amazed at how many of these Free Software accounting packages
don't use fixed-point arithmetic!  I think that may need to be a first patch
to any one we pick.

> if you are designing a new accounting application from scratch (I don't
> understand why but that's another discussion)

Actually, let's start to have that discussion.  While there will certainly be
some code reuse in this project [0], what we're finding in our initial
evaluations is that so many of these codebases made design decisions for a
specific clientele that make the systems needlessly complex in one area while
lacking features we need in another area.  These codebases we're looking at
are amazingly baroque and complex for the level of features presented to
solve what is a relatively well-explored problem (I mean, the first
accounting systems were written in the 1960s, after all!)

I don't know if anyone else has actually *done* a full evaluation of what
code is available out there for accounting software, so I think maybe Joar
and I are the first to dig deeply into "compare and contrast", but if someone
did this work before, I wouldn't blame them from starting again from scratch.

My proposal about some sort of API is that I'm rarely finding in these
codebases clear separation of baroque domain-specific features from reusable
code.  This is one reason why I've encouraged others on this list to help us
with the evaluation process, as I don't want us to miss any diamonds in the
rough... please do come by IRC if you have time or post on the Wiki.

[0] The closest to "start from scratch" that we'll get is we'll use
    Conservancy's existing Ledger-CLI setup as a base and build a GUI around
    it.  I think many people who have contributed to Tryton, LedgerSMB, etc.,
    will tell us "we're starting from scratch" if we do that, but it's not
    exactly right, given that Ledger is a pretty strong double-entry
    accounting system, just with a very limited UI (command line only).

   -- bkuhn


More information about the npo-accounting mailing list