[Vtigercrm-developers] Ideas for vtiger architecture moving forward

Dennis Grant dgrant at accuratetechnologies.com
Fri Jul 14 12:37:08 PDT 2006


> 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  




More information about the vtigercrm-developers mailing list