From: "Sean Russell" <ser / germane-software.com>
>
> Curt Hibbs wrote:
> 
> > XP is does not really advocate "never break the rules". The XP
> > guidelines explicitly say its not necessary to "swallow the XP elephant
> > whole", but rather to use what works for you (or your organization) in
> > its current context. XP advocates would contend that the more XP
> > practices you adopt the more benefits you will realize.
> 
> Hmm.  I distinctly remember Kent Beck, in "XP Explained" saying that if you 
> aren't doing all (5?) of the XP "rules" at 100%, you aren't doing XP.  I 
> read that to mean:  if you break the rules, you aren't doing XP, which to 
> me means: don't break the rules.

[sorry so OT for ruby, but . . . gotta jump in before godwin strikes ;)]

I find the tone and attitude on the XP list to be much more like what
Pete McBreen wrote in [ruby-talk:24734], "Hence you never _break_ any
rules, you are continually changing the rules to match what is sensible
for your circumstances."

The refrain, though, is that it's actually recommended to _try_ the full
set of XP practices together, or as many as possible as fit your 
situation, for a few iterations, before deciding this one or that one
isn't applicable. . . which makes sense to me and is what we finally
committed to on our last project.  (Which was successful, and fun, and
delivered on-time, and didn't end in a death march, and had close to no
bugs slipping through the unit tests, etc.)  

. . . To get slightly back on topic re: execution speed, optimizations
vs. well-factored clean code, etc.  On this project above, we were 
working in Java, but did as much coding as possible in Jython.  Because,
frankly, well if we liked programming Java we probably wouldn't be
hanging out here on the Ruby list.  :-)  Now if JRuby had been available
when we started of course there would have been no contest, and that's
what we would have been using.  But I suspect the speed-performance
issues we ran into with Jython would be similar with JRuby.

As I mentioned we wrote as much code as possible in Jython.  This included
our HTML parser, layout engine, and renderer.  We were aware performance
was a real risk here, and we did some profiling up front and along the
way to try to monitor whether it was going to be an issue.  We had some
confidence of it being OK because we knew in advance the maximum size
HTML document we needed to render in this product.  Anyway of the three
components there, the layout engine ended up being too slow in Jython.
(The parser used a lexer that was pure regexp, and which did most of
the work, so the parser itself was very simple Jython.)

Anyway, the time came when we needed to rewrite all or part of the 
layout engine in Java.  We tried some tweaks to the Jython implementation
to see whether there was any chance of optimizing things there.  But
the method invocation overhead in Jython is just horrendous.

Anyway, the point, if I can ever get around to it, is kind of two-fold.
One, we were using a high-level language because we wanted to write
the most high-level, clean code we could.  I don't find myself willing
to second-guess or in the sense of premature optimization try to foretell
what part of the code *might* need to be "ugly" beforehand.  (Ugly
meaning twisted by performance optimizations.)  I mean, what's the 
point of using a high-level language if one is tempted to introduce
ugliness in the code.  At that point I sincerely maintain it's worth
considering whether one might be better off dropping to a lower-level
language for that part of the code.  And write it cleanly.  I think I
prefer our layout engine rewritten in Java, and kept the clean OO
architecture, than some kind of crazy-ass machinations [hypothetically]
possible in Jython that would have uglified the code but made it run
fast enough.

And anyway (again? - I keep saying that:) point two was that this was
all in the context of an XP project.  Our unit tests, in fact, were
immensely helpful in the rewrite of the layout engine in Java.  The
module still uses its original Jython unit tests, and it was great-
nay, superb!-having them there while the rewrite was being implemented.

So . . .. . if I get a chance to do another project this time in
JRuby, I will jump at it.  And I will plan to be still in the mindset
of writing the most high level code I can.  If some part of it 
eventually has to be optimized, so be it.  I don't see how it's in
conflict with XP's "Simple Design" principle.  At least it didn't
turn out that way on our project.


BTW - just as incidental information - a rather nicely formulated
'what is XP' FAQ was posted online yesterday:
http://www.xprogramming.com/xpmag/whatisxp.htm


Regards,

Bill