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