Re: Proposal for 1.6 and above: small new-code-only developer release

Hi Kaare,

Just my 0.02 <currency>:

Your contribution is much appreciated!

> This is a question which comes up fairly often I think. There are a
> number of questions in response to that that I think are worth coming up
> with answers to:
>
> * Does it seem like some form of usable package can be formed when you
> end up throwing out all "old code" right now?
> * Are you looking at creating two sub projects (which might in the
> future be merged into a single project again)?
> * What are your main goals in throwing out all the "old code which we
> haven't been able to replace"?

I understand all the reservations. The world is full of dead and
abandoned project rewrites. In this case though, I think there is more
point in doing it than in most other cases.

Fully agreed. There's no doubt in my mind that the old code has to go.

The code is scattered over several modules, not from a design
perspective, but for historical, or 'this is just the way it is'
reasons. This kills maintainability. My own quest into 1.5 is a sign of
this, I think.

Absolutely. [Thanks, for sticking with us and providing all the feedback that you have!]

That the system works at all is down to the amazing work
of the developers.

But Chris put it something like this in a discussion:
In most projects, you'll improve your efficiency by a factor with the
knowledge you get from digging in the code. In LedgerSMB it's like
starting all over again, every time.

I know the feeling. Although, it gets better if you work on it full-time for extended periods of time.

The design is very much a product of ad hoc thinking in the original
SQLedger, basically making extendability, or even natural development hard.

Worse, actually: the code can't be maintained without creating new issues. I've found this every time I have to fix a bug.

If ever there is a rewrite, I would expect that an upgrade path would be
one of the design goals that can't be waived.

Ah, but there already *is* a rewrite on-going! Over the last year I have changed ample lines of code in the "old code" code base. There's a lot of business logic in code that has been written since 2009.

I understand the concern about the resources being spread too much. It's
just my experience that a well-designed, well-maintained system is many
times more responsive to developer effort. Or in other words, a poorly
crafted system is a time sink. Building on quicksand is never a good idea.

Agreed. The current strategy is to quarantine the "old code": I'm not changing it unless there's a critical bug to be fixed. At the same time, we're putting in place replacement infrastructure that *is* based on modern techniques and technologies - and more importantly *a design* (based on workflows).

Doing things this way, we can maintain the workflows for our existing users while gradually bringing the new infrastructure in place. This means: Building the UI components (Dojo, or other) which we need for the workflows and building web services to provide business logic and functionality to that UI. By going about that way, we automatically separate the UI and business logic concerns. At this point, what stands in the way of developing the first web services and further advancing the client-side UI, is the 1.5 release. That is, not that the 1.5 release by itself is a bad thing, absolutely not, it's a good thing, but it's a point where we're driving the code base "back" to stability without changing much (if any) of the functionality. That costs time. However, I think it's something that's required in every code base: there are periods of heavy turn-over and periods of consolidation.

As such, I think we're almost at a point where we can actually start removing chunks of old code which have been replaced with new and better functionality. I'm as eager as you to see the commits actually achieving this.

In the mean time, we've been developing in-browser tests which should help us to assess that the most basic workflows and functionalities remain functional while we're replacing the plumbing -- basically, each release between 1.3 and 1.5 was problematic in that sense that "obvious" workflows were broken by simple fixes/changes. And since we'll need those tests after we install the new plumbing anyway, "now" is a good time as any to develop them.

I'm impressed that you've managed to go where you've gone from the
original sources. I just think there's even more to do to get up to par
with tomorrow's, or even today's, standards. That's why I think it's
the way to go.

Just my opinion, of course. Formed by testing, looking at code and
database schema, and discussing things on and off list.

Much appreciated, thanks!

While I understand your route and choices, the question is if you'd be looking at using LedgerSMB at all, if there had been no way to enter invoices and/or AR/AP transactions today (although the promise would be that you'd be able to in two years)? I'm certain that *I* wouldn't. What's more, until now, I've been using almost all of the released versions between 1.3.0 and 1.4.30 for some amount of time.

With the current approach, I've been able to enjoy many of the improvements that we've put in place within a matter of weeks after the implementation (another reason for frequent releases). With the approach to "scrap it and replace it" I'm affraid the project will be dead before there is a replacement (I'm almost certain a replacement /which is of certain quality/ will take *years*, especially with the size of our current team).

Concluding: we agree on all points except for one thing: how to get there.

--

Bye,

Erik.

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

Robust and Flexible. No vendor lock-in.