[Vtigercrm-developers] Ideas for vtiger architecture moving forward

[Matthew Brichacek]

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.

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.

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.

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?

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.

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.  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.

Matt

On Fri, 2006-07-14 at 15:37 -0400, Dennis Grant wrote:
> > Really what I am trying to accomplish is to make your life easier in
> the
> > long run than what it currently is, even when diverging from the
> > standard way of doing it with-in vtiger.  There is a learning curve
> that
> > will come along with this but correct documentation and developer
> > support via this mailing list should help you get past any of that.
> 
> Except that you're killing me with your good intentions.
> 
> The life of an integrator doesn't permit steep learning curves and heavy
> abstractions; there just isn't time to do so. I've got a dozen different
> systems to get to play together, a boss screaming at me to get this
> stuff done yesterday, and no time to devote to learning whatever
> abstraction layer you've decided to implement.
> 
> And Murphy's Law being what it is, if your abstraction model has one
> flaw, that will be the thing that my boss wants as his top priority.
> 
> "Perfect is the enemy of good enough" I don't want "perfect"; I want
> "good enough" I want to be able to dive into the source and start
> modifying how the thing works *right now* without having to trace back a
> billion functions or wrap my brain around your object model. I don't
> have time to do so, because I'm simultaneously trying to play with a
> dozen other pieces of the puzzle.
> 
> Guys, I have been playing this game for a LONG time. I have written
> major applications to perform mission-critical business functions.(At
> one time, if my code broke DaimlerChrysler stopped building cars) I have
> seen and dealt with thousands of software projects, both as a
> participant and as an observer, and almost without fail, every time
> somebody sets out to do the "perfect" object-based, extensible,
> customizable framework, it just leads to tears.
> 
> I am utterly convinced that the way to success is to write code that is
> optimised for human legibility and comprehension. If you write code that
> any decent developer can pick up, find his bearings in a couple of
> seconds, and then comprehend *without* the benefit of having read the
> thousand-page project definition in advance, then you are doing well.
> 
> The second I have to go to a developer list to get assistance you, as a
> developer, have FAILED ME as an integrator - because if your code is so
> illegible (or so heavily abstracted, or has such a steep learning curve,
> or whatever) that I cannot figure it out on my own in a few minutes and
> so have to drop everything until I can get some assistance... well then,
> you've burned up my precious, precious time.
> 
> That code might be sheer genius. It might be, once you have tackled the
> learning curve, breathtakingly beautiful. But if I can't just fire up vi
> and dive in, then it is WRONG.
> 
> 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.
> 
> The big problem with the current state of Vtiger 4.x is that it
> straddles both worlds. There are parts of the code that are fairly
> straightforward and out in plain sight, and only lack comments to make
> them "good enough". Then there are parts that want to be object-oriented
> with an API, but really depend on a couple of heavily-overloaded
> megafunctions buried deep in the depths of util.php (also uncommented)
> so you have to play API detective to figure out just what the hell is
> happening where. And then there's parts of the code that mix both.
> 
> It'd be SO much easier to maintain if all the code that related to a
> module (less some *basic* toolkit functions that could reside in a
> common include) just lived in that module.
> 
> Please please PLEASE, for the love of GOD, don't go down the path of
> objectifying everything and abstracting the code to the point of
> incomprehensibility.
> 
> DG  
> 
> _______________________________________________
> Get started with creating presentations online - http://zohoshow.com?vt