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.
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
