Re: Ideas for vtiger architecture going forward

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Ideas for vtiger architecture going forward

Dennis Grant

> OK, so I am going to highlight and comment on some of my favorite
quotes
> from DG so far, this way when I start ignoring his emails you will all
> understand why.

This is entirely the wrong attitude. You asked for my opinion, and I
told you. It's not MY fault if I don't agree with you.

You don't live in an ivory tower where you get to make proclamations
from on high and all the peons get to live with your decisions; you are
part of a COMMUNITY - and communities are, by nature, PARTICIPATIVE.

That means you have to listen to the people who are actually using your
code in production environments, who have experience with these
environments, and who deal with the consequences of your decisions on a
daily basis.

Something you are going to find out is that people downstream from you
are going to do things with your code that will continually surprise and
shock you. "I NEVER intended THAT!" is a fact of life for a developer.

Here's a reality check for you - you do not have a monopoly on brains.
"Your way" is almost certainly not the optimal way to deal with any
particular problem.

And the other side of that coin is that MY way, or Sergio's way, or
anybody else's way is not going to be optimal EITHER. Project design is
a series of tradeoffs and compromises working toward a common goal.

You had better learn this in a hurry, or you will find yourself
marginalized in a hurry. Free Software projects have a way of seeing
ivory-tower developers as damage and routing around them. You do not
have the option of taking your ball and going home.

LISTEN TO WHAT I HAVE TO SAY. Put your ego aside, and understand WHY it
is I am telling you the things that I am telling you. I am maintaining a
fork of Vtiger that is running an actual live business; I am not pulling
this stuff out of my ass.

>> 1) It is a whole lot easier to deal with each module having its own
>> code, even if that code is 95% common with other modules.

> This has to be hands-down the stupidest thing I have ever heard in my
> life and I can't believe that anyone who claims the experience you do
> actually posts this drivel on a public mailing list.

So in other words, you don't understand. Fine, I'll explain it to you
again:

My job, and the job of any integrator, is getting systems to talk to
each other to work, from the outside, as a unified whole, as quickly as
humanly possible. Non-IT bosses have little to no understanding of the
complexity of systems integration and they have no patience with delay.

For example, my boss wants the generation of a Quote in VTiger to call
Microsoft Great Plains (for better or worse, the back-end business
software I have to deal with) and pre-order all the component parts that
make up the assemblies that are being quoted in the Quote. Then he wants
the promotion of the Quote to a Sales Order to trigger a manufacturing
order in GP so the parts get built. Then he wants the generation of an
Invoice in Great Plains to create an Invoice in Vtiger - and he wants
this to all happen with minimal to no human data entry.

Oh, and he wants the Quote, Sales Order, and Invoice numbers in VTiger
and GP to be the same.

And he wants it done in two weeks.

And this is typical of the sort of thing I have to deal with. I've
already written a query and display engine into our Software Licensing
System, and I wrote (from scratch) a company Org Chart application that
displays the relationships between Accounts in the CRM, and between
Contacts within an Account (both currently implemented as standalone web
services, but I've been told he wants them displayed as CRM tabs)

I flat out do not have the luxury of the time required to study and
learn new APIs all the time. It is bad enough that I have to deal with
Microsoft doing this to me; I sure the HELL don't want vTiger doing this
to me.

Plus, if the API isn't flexible enough to do what I am REQUIRED to make
it do, then I wind up having to RE-IMPLEMENT that section of Vtiger to
NOT use the API - which is wasteful of my time and your time, and severs
the tie between vanilla Vtiger and my private fork, which is bad for
BOTH of us (as we no longer get the benefits of each other's bug fixes)

Plus... like I've said, I've been at this a long time. I have seen
hundreds of projects waste millions of dollars trying to define the
"perfect" API and object model, only to have it blow up in their face -
usually because making the object model "perfect" took three times
longer than anticipated, and then when they first present it to the
user, the user goes "but that's not what I wanted" and (Murphy being
Murphy) their object model is utterly incompatible with what the user
wanted.

I have seen exactly ONE object-oriented project succeed - the Chrysler
employee pay system was written in Smalltalk, and it was BRILLIANT. It
also had the benefit of a very tightly integrated development team, and
a team lead who had the object religion in a big way and converted his
team to it utterly. Part of his design process was that you were not
allowed to code a single byte until you had defined the entire object
(data and methods) on paper, it had passed his review, and then passed
an open team review. It took around two months of paperwork and design
review before you were allowed to write actual code.

I was amazed at their discipline, and the project as a whole really
impressed me - but they also had the advantage that (for legal reasons)
their system had to be 100% standalone and was not allowed to interface
with any other systems. You needed special access just to get into their
portion of the building; it was walled off from everybody else.

This project is 180 degrees off from that, and there is simply no way
that sort of design methodology could work in this situation.
   
>> 2) I am utterly convinced that the way to success is to write code
that
>> is optimised for human legibility and comprehension.

> I am utterly convinced that anyone who argues that 95% code
similarities
> in vtiger modules is a "good enough" method is utterly stupid.

You don't understand WHY, obviously, I would say this.

The utter worst case scenario for an integrator is changing code in
Module A and then functionality changes in Module B. I'm pounding away
on Sales Orders, and suddenly, Quotes stop working - or (as happened
recently) I start working on the Email module, and suddenly all our
users are being emailed copies of our Helpdesk Tickets. Holy hell!

Modules MUST MUST MUST MUST MUST MUST MUST be atomic. Can you possibly
argue against that?

Now, the simplest way to achieve that is to have separate copies of
common code in each module - right?

Now you may well argue that having separate copies of common code in
each module makes maintaining common code a SERIOUS pain in the ass -
and I agree wholeheartedly. The trick is separating out REAL common code
from "code that is common by convenience"  I am not opposed to REAL
common code being placed into functions. What I AM opposed to are
functions that exist like some of the ones in utils.php where you pass
the function a UItype (which is a meaningless number) and then you get
this huge cascading IF statement like this:

If ($uitype == 63) {
 
    If ($module == 'CONTACTS' || $module == 'HELPDESK'') {

         Do this();
    }
    Else {

        Do that();
    }
}

That is NOT common code.

Do you see this? DO you understand? Do you have ANY idea how much time
has been wasted tracking down stuff like this?
 
>> 3) The second I have to go to a developer list to get assistance you,
as
>> a developer, have FAILED ME as an integrator ... well then, you've
>> burned up my precious, precious time

> So your 'job' as an OSS systems integrator has never included needing
to
> RTFM or actually expand your horizons or even.. *GASP* ask a fsck'ing
> question on a mailing list?

All the time. But OSS documentation, typically (and in Vtiger,
EXPLICITLY) SUCKS. And responses on mailing lists vary greatly in terms
of quality of response, timeliness, and applicability. I cannot afford
to be dead in the water waiting on a response from a mailing list;
there's just too much damn work to do to be held up waiting on someone
who may or may not respond. And let's be honest here, up to this point,
the Vtiger team has been singularly unresponsive - perhaps that will
improve, but as of right now, if I had to wait in the dev team to answer
my questions, I would never have gotten anything done.

Good code is self-documenting. If I can't figure out what the code is
doing by reading the code, the developer has failed, no matter how
functional the code might be.

>> 4) That code might be sheer genius. But if I can't just fire up vi
>> and dive in, then it is WRONG.

> I'm starting to see the picture now.. you're lazy, and rather than do
> something about the current problems in the system you are going to
> whine about it.  Sergio was right, my apologies Sergio.

Right, I'm so lazy that I'm investing hours of my time trying to educate
you as to WHY I feel the way I do, in the hope that I won't be forced to
re-invent the wheel or fork the bloody project.

I'm not "whining", I am TEACHING.

>> 5) Do you see what I'm getting at? Keep it SIMPLE and you win.
Overthink
>> it, and you'll wind up with something that only YOU understand... and
>> I'm back with my privately-maintained fork.

> I think I've made it clear that simple, concise and logical are all
> design goals of the system.

But you have done no such thing, because you are rejecting my trenchant
and entirely valid points out of hand because they contradict your
personal world view.

> And you sir have made it clear that you
> have no intention of helping move this project forward by displaying
> your willingness to fork instead of work with a _real_ design
structure
> that a _real_ OSS systems integrator would be very happy to have.

1) I most certainly do NOT want to fork. I am trying, with all my might,
to AVOID a fork. Forking hurts EVERYONE. But if you implement some
ivory-tower API and object model such that it is LESS painful to fork
than it is to deal with your model, then you will have FORCED me to
fork.

2) I AM a real OSS integrator. I am telling you what it is like out in
the real world. Put your ego aside for a while and LISTEN.

DG

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: Ideas for vtiger architecture going forward

Richie-4
Hi Team!

Let us take a step back and review what is happening.

As the case stands, the intent is to provide an ideal vtiger architecture which needs almost everyones needs.

It is plain that as of now, there are only 2 "strong/loud" arguments.
I am sure you all will agree that both of them are not overly subscribed by any majority yet.

Let us get some more ideas- however radical they be- into this list and then we will vote the good ideas in. By being too strongly worded on any particular idea, it will only stop short the other guys to put forth their ideas however miniscule/insignificant that might appear to be.

I have myself faced this situations many times and I wish that the same does not happen here.

Let us target 2 weeks from today as the time within which we should get all the ideas in. We can always short list as we have quite some experienced hands on board.
vtigercrm-5.0.0 will be out within that time.

Good to see some emotion here but I am sure we will hold to the rules of basic etiquettes and only wrt the point in concern.

Thank You,
Richie




---- Dennis Grant<[hidden email]> wrote ----


> OK, so I am going to highlight and comment on some of my favorite
quotes
> from DG so far, this way when I start ignoring his emails you will all
> understand why.

This is entirely the wrong attitude. You asked for my opinion, and I
told you. It's not MY fault if I don't agree with you.

You don't live in an ivory tower where you get to make proclamations
from on high and all the peons get to live with your decisions; you are
part of a COMMUNITY - and communities are, by nature, PARTICIPATIVE.

That means you have to listen to the people who are actually using your
code in production environments, who have experience with these
environments, and who deal with the consequences of your decisions on a
daily basis.

Something you are going to find out is that people downstream from you
are going to do things with your code that will continually surprise and
shock you. "I NEVER intended THAT!" is a fact of life for a developer.

Here's a reality check for you - you do not have a monopoly on brains.
"Your way" is almost certainly not the optimal way to deal with any
particular problem.

And the other side of that coin is that MY way, or Sergio's way, or
anybody else's way is not going to be optimal EITHER. Project design is
a series of tradeoffs and compromises working toward a common goal.

You had better learn this in a hurry, or you will find yourself
marginalized in a hurry. Free Software projects have a way of seeing
ivory-tower developers as damage and routing around them. You do not
have the option of taking your ball and going home.

LISTEN TO WHAT I HAVE TO SAY. Put your ego aside, and understand WHY it
is I am telling you the things that I am telling you. I am maintaining a
fork of Vtiger that is running an actual live business; I am not pulling
this stuff out of my ass.

>> 1) It is a whole lot easier to deal with each module having its own
>> code, even if that code is 95% common with other modules.

> This has to be hands-down the stupidest thing I have ever heard in my
> life and I can't believe that anyone who claims the experience you do
> actually posts this drivel on a public mailing list.

So in other words, you don't understand. Fine, I'll explain it to you
again:

My job, and the job of any integrator, is getting systems to talk to
each other to work, from the outside, as a unified whole, as quickly as
humanly possible. Non-IT bosses have little to no understanding of the
complexity of systems integration and they have no patience with delay.

For example, my boss wants the generation of a Quote in VTiger to call
Microsoft Great Plains (for better or worse, the back-end business
software I have to deal with) and pre-order all the component parts that
make up the assemblies that are being quoted in the Quote. Then he wants
the promotion of the Quote to a Sales Order to trigger a manufacturing
order in GP so the parts get built. Then he wants the generation of an
Invoice in Great Plains to create an Invoice in Vtiger - and he wants
this to all happen with minimal to no human data entry.

Oh, and he wants the Quote, Sales Order, and Invoice numbers in VTiger
and GP to be the same.

And he wants it done in two weeks.

And this is typical of the sort of thing I have to deal with. I've
already written a query and display engine into our Software Licensing
System, and I wrote (from scratch) a company Org Chart application that
displays the relationships between Accounts in the CRM, and between
Contacts within an Account (both currently implemented as standalone web
services, but I've been told he wants them displayed as CRM tabs)

I flat out do not have the luxury of the time required to study and
learn new APIs all the time. It is bad enough that I have to deal with
Microsoft doing this to me; I sure the HELL don't want vTiger doing this
to me.

Plus, if the API isn't flexible enough to do what I am REQUIRED to make
it do, then I wind up having to RE-IMPLEMENT that section of Vtiger to
NOT use the API - which is wasteful of my time and your time, and severs
the tie between vanilla Vtiger and my private fork, which is bad for
BOTH of us (as we no longer get the benefits of each other's bug fixes)

Plus... like I've said, I've been at this a long time. I have seen
hundreds of projects waste millions of dollars trying to define the
"perfect" API and object model, only to have it blow up in their face -
usually because making the object model "perfect" took three times
longer than anticipated, and then when they first present it to the
user, the user goes "but that's not what I wanted" and (Murphy being
Murphy) their object model is utterly incompatible with what the user
wanted.

I have seen exactly ONE object-oriented project succeed - the Chrysler
employee pay system was written in Smalltalk, and it was BRILLIANT. It
also had the benefit of a very tightly integrated development team, and
a team lead who had the object religion in a big way and converted his
team to it utterly. Part of his design process was that you were not
allowed to code a single byte until you had defined the entire object
(data and methods) on paper, it had passed his review, and then passed
an open team review. It took around two months of paperwork and design
review before you were allowed to write actual code.

I was amazed at their discipline, and the project as a whole really
impressed me - but they also had the advantage that (for legal reasons)
their system had to be 100% standalone and was not allowed to interface
with any other systems. You needed special access just to get into their
portion of the building; it was walled off from everybody else.

This project is 180 degrees off from that, and there is simply no way
that sort of design methodology could work in this situation.

>> 2) I am utterly convinced that the way to success is to write code
that
>> is optimised for human legibility and comprehension.

> I am utterly convinced that anyone who argues that 95% code
similarities
> in vtiger modules is a "good enough" method is utterly stupid.

You don't understand WHY, obviously, I would say this.

The utter worst case scenario for an integrator is changing code in
Module A and then functionality changes in Module B. I'm pounding away
on Sales Orders, and suddenly, Quotes stop working - or (as happened
recently) I start working on the Email module, and suddenly all our
users are being emailed copies of our Helpdesk Tickets. Holy hell!

Modules MUST MUST MUST MUST MUST MUST MUST be atomic. Can you possibly
argue against that?

Now, the simplest way to achieve that is to have separate copies of
common code in each module - right?

Now you may well argue that having separate copies of common code in
each module makes maintaining common code a SERIOUS pain in the ass -
and I agree wholeheartedly. The trick is separating out REAL common code
from "code that is common by convenience" I am not opposed to REAL
common code being placed into functions. What I AM opposed to are
functions that exist like some of the ones in utils.php where you pass
the function a UItype (which is a meaningless number) and then you get
this huge cascading IF statement like this:

If ($uitype == 63) {

If ($module == 'CONTACTS' || $module == 'HELPDESK'') {

Do this();
}
Else {

Do that();
}
}

That is NOT common code.

Do you see this? DO you understand? Do you have ANY idea how much time
has been wasted tracking down stuff like this?

>> 3) The second I have to go to a developer list to get assistance you,
as
>> a developer, have FAILED ME as an integrator ... well then, you've
>> burned up my precious, precious time

> So your 'job' as an OSS systems integrator has never included needing
to
> RTFM or actually expand your horizons or even.. *GASP* ask a fsck'ing
> question on a mailing list?

All the time. But OSS documentation, typically (and in Vtiger,
EXPLICITLY) SUCKS. And responses on mailing lists vary greatly in terms
of quality of response, timeliness, and applicability. I cannot afford
to be dead in the water waiting on a response from a mailing list;
there's just too much damn work to do to be held up waiting on someone
who may or may not respond. And let's be honest here, up to this point,
the Vtiger team has been singularly unresponsive - perhaps that will
improve, but as of right now, if I had to wait in the dev team to answer
my questions, I would never have gotten anything done.

Good code is self-documenting. If I can't figure out what the code is
doing by reading the code, the developer has failed, no matter how
functional the code might be.

>> 4) That code might be sheer genius. But if I can't just fire up vi
>> and dive in, then it is WRONG.

> I'm starting to see the picture now.. you're lazy, and rather than do
> something about the current problems in the system you are going to
> whine about it. Sergio was right, my apologies Sergio.

Right, I'm so lazy that I'm investing hours of my time trying to educate
you as to WHY I feel the way I do, in the hope that I won't be forced to
re-invent the wheel or fork the bloody project.

I'm not "whining", I am TEACHING.

>> 5) Do you see what I'm getting at? Keep it SIMPLE and you win.
Overthink
>> it, and you'll wind up with something that only YOU understand... and
>> I'm back with my privately-maintained fork.

> I think I've made it clear that simple, concise and logical are all
> design goals of the system.

But you have done no such thing, because you are rejecting my trenchant
and entirely valid points out of hand because they contradict your
personal world view.

> And you sir have made it clear that you
> have no intention of helping move this project forward by displaying
> your willingness to fork instead of work with a _real_ design
structure
> that a _real_ OSS systems integrator would be very happy to have.

1) I most certainly do NOT want to fork. I am trying, with all my might,
to AVOID a fork. Forking hurts EVERYONE. But if you implement some
ivory-tower API and object model such that it is LESS painful to fork
than it is to deal with your model, then you will have FORCED me to
fork.

2) I AM a real OSS integrator. I am telling you what it is like out in
the real world. Put your ego aside for a while and LISTEN.

DG

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt

_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt 
Reply | Threaded
Open this post in threaded view
|

Re: Ideas for vtiger architecture going forward

Matthew Brichacek
> It is plain that as of now, there are only 2 "strong/loud" arguments.
> I am sure you all will agree that both of them are not overly
> subscribed by any majority yet.
Yes but there is only one idea on the table, and 1 set of criticisms
followed by absolutely no suggestions on how to better the first idea.
This was really my bitch about the first set of posts.

>
> Let us get some more ideas- however radical they be- into this list
> and then we will vote the good ideas in.
This is a great idea.  I have been looking forward to someone else
posting some ideas to get the ball rolling.  I for one welcome radical
ideas if anyone has any.

> By being too strongly worded on any particular idea, it will only stop
> short the other guys to put forth their ideas however
> miniscule/insignificant that might appear to be.
I certainly don't mean to scare off any developers that are going to
actually bring some ideas to the table, quite the contrary.  If someone
has been playing around in 5.x and said to themselves "wouldn't it be
easier if this was done like this..." then please tell us what you are
thinking, even if it doesn't involve a full change to the architecture
and only covers some small area of the code.

>
> I have myself faced this situations many times and I wish that the
> same does not happen here.
>
> Let us target 2 weeks from today as the time within which we should
> get all the ideas in.
Lets not rush this, or pile on top of the workload that many vtiger
devels are probably already experiencing.  The only reason I brought my
idea to the table this soon is because you and I had discussed this off
list and I thought it needed to be in front of the community.


> We can always short list as we have quite some experienced hands on
> board.
> vtigercrm-5.0.0 will be out within that time.
But after 5.0.0 is out is when I think we'll start to see the most
interesting ideas.  Many devels may still be in 4.x and haven't had a
chance yet to start playing with 5.x.  Lets let them get their hands
dirty in the new code first.

>
> Good to see some emotion here but I am sure we will hold to the rules
> of basic etiquettes and only wrt the point in concern.
I know I am a blunt person and sometimes that catches people off
guard :), I rarely mean to come off as rude unless someone fully
deserves it.

Anyways, bring on the ideas for improving vtiger!

Matt


_______________________________________________
Get started with creating presentations online - http://zohoshow.com?vt