Hi,
On 07/15/2016 02:16 AM, Erik Huelsmann wrote:
Hi Chris,
One of the difficulties we have had for a while is the ability for
new developers to come in and contribute, in part because of the
code quality of the older code layers (most particularly the SQL
Ledger codebase but also our earlier work) One possibility would
be to establish a parallel release that would only be new code.
One reason we haven't done that is that right now, if we did this,
we couldn't meet anyone's needs.
Thanks for bringing this up! It also very much relates (IMO) to the
thread I started some time ago about a next-10-years vision
(http://archive.ledgersmb.org/ledger-smb-devel/msg06409.html).
Not entirely opposed to the idea, but I think the focus should be on the
overall system design -- don't want to get sucked into too much
module-by-module rewriting.
I'm thinking we should be focused on three key design areas:
- What is the desired user experience we want to have? The BDD tests are
crucial for this, and we should develop those before doing any forking
into parallel branches.
- What sort of API can we put in place to act as a contract between the
user experience, any external integrations, and the back end?
- Do we have the best underlying data schema in place going forward?
(E.g. the multi-currency stuff that Erik has created -- are there any
other ways our current schema limits what LSMB can do effectively?)
I think a strong focus on these 3 key areas will make our project
progress based on a much more cohesive intention, rather than fighting
fires/bugs/fixing things as they arise and doing battle with the old code...
I would like to see us develop these 3 things first, define what we want
the system to do and how we want it to behave -- and try to wrap as much
of the old code in as possible. I do expect we may hit some big
roadblocks in some parts of the code that are just not possible to wrap
or fix without rewriting -- but how many of these have you already blown
through and rewritten? I suspect with proper design, it may be possible
to rewrite the implementation much more quickly, making the new code
work the way it should work, and not just a better version of a crap design.
There's a rather fundamental question to be asked here, if you bring
up the "on boarding of other developers", which might come down to a
"chicken and egg problem": should we expect more developers to be
joining the team? I mean, is there a group of developers out there
that we expect to be able and willing to contribute to our accounting
application?
It just so might happen to be that (apart from the fact that we were
lucky to have 2 in the first 6 months of the year), there are
extremely few devs who would love to work on LedgerSMB (or any other
web-erp) instead of some hyped app.
I don't think we need to focus on onboarding other developers. I do
think we should start more marketing. I think the work Erik has been
doing on BDD is fantastic, and if we start talking about it more, we're
sure to attract other developers. And if we have a solid API and BDD
framework, I think it will be easier to solicit contributions from new
developers...
And if such a group of developers were to exist, what would stir their
interest in LedgerSMB instead of in, say, Odoo? Wouldn't having
something that *almost* works be a better choice for a business to run
their operations on? And from there, contribute to the further
development of the application.
Totally agree here -- having something that mostly works and a bunch of
companies using it, and evolving that to better tested, more reliable
code is a big win. While I do think it's a good idea to start a fresh
branch with only working code, that also becomes a huge barrier to
contribution if nobody is using that code in production. It becomes such
a massive undertaking with really far-off payoff.
I mean, I would love if somebody would do this work -- AFTER we know
what it should look like, with as much of the new design dropped into
the currently working version as possible. As long as it got done at
sometime useful, and didn't happen at the expense of having a working
production version.
But I was thinking. With the current work regarding GL, maybe in
1.6 we could start with a parallel release which would include
only fully re-engineered code.
I can see how that would an absolute relief :-) However, do we think
we can attract new developers with it? I mean, looking at yourself:
would you join a team with the perfect code base, even though you
can't really use the product yet? Or would you join a team where you
can use the product, but simply want it improved, because the code
base has real problems?
Maybe we can put new API/interfaces in as stubs, build out the whole
design in the current release? Throw "unimplemented" exceptions where
the new code isn't built yet, build the parallel functionality in the
current release and migrate stuff over a chunk at a time?
<snip>
Basically, from a development point of view, I've taken exactly this
approach, btw: I've been working around the old code, putting a
foundation in place which can replace the old code after we rip it
out, without ever needing to touch the old code. In that sense, the
existence of the old code in the code base hasn't bothered me much
over the past year, other than that I have had to fix bugs in our old
code, because people were running into problems.
Yes, exactly -- I think we should continue this approach.
<snip>
As for removal of old code: I don't see that as a goal by itself. I
see it simply as a means to move the LedgerSMB code base to a point
where we can have a much better agility in bug-fixing, where we can be
much more extensible and open to integration with surrounding systems.
Agreed...
Happy to add more later, but gotta run, camping weekend ahead!
Cheers,
John Locke
http://www.freelock.com
------------------------------------------------------------------------------
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
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel