[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ledgersmb development
- Subject: Re: ledgersmb development
- From: "Chris Travers" <..hidden..>
- Date: Sat, 9 Aug 2008 08:54:16 -0700
On Sat, Aug 9, 2008 at 5:18 AM, Jeff Kowalczyk <..hidden..> wrote:
> Armaghan Saqib wrote:
>> Things You Should Never Do
>> http://www.joelonsoftware.com/articles/fog0000000069.html
>>
>> With all respect and best wishes for LSMB Project.
>
> Agreed, and the decision not to do a full rewrite is in the record. I
> would characterize the roadmap as I understand it for LedgerSMB 1.3
> through 2.0 as a rewrite on a module-by-module basis, with supported
> migration throughout.
That is correct. Also, the big reason we chose not to rewrite
*everything* from scratch at once was because there was a strong
concern that such a project would get completed sometime after Duke
Nukem Forever, HURD, and Perl 6.
The problem is that there are fundamental architectural problems with
the current code, and the current code is somewhat more difficult to
read than it should be. The fundamental problem that Joe mentions is
that it is almost always better to improve code than to rewrite it
from scratch because this *usually* results in less maintainable code.
Unfortunately in our case, maintaining the legacy code is unusually
hard, so the cost equation is different. (For laughs, I went through
the list of software antipaterns on Wikipedia and found that about 75%
of them applied to the code we inherited.)
Also, we are taking our time with the rewrite, shimming things first,
gathering requirements, and ensuring that what we do is really correct
and works for everyone. Although 1.3 is starting really shaping up, I
expect 1.4 may be a ways off.
Just because we are rewriting the code does not mean we are not adding
features to the old code either. The decision was not arrived to
quickly-- we didn't decide to do this until we had around a year of
experience with the problems in the current codebase, so it is not an
uninformed decision based on all of the costs involved.
If anyone else has anything to add, they are welcome to do so.
Best Wishes,
Chris Travers