------art_44615_29486197.1146665141815
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I am a fan of agile programming, but it has its places.

XP is not good for product development, although it excels for projects (e.g.,
professional services companies building a web site for a client.)

By and large, XP focuses groups away from domain expertise... this is a
problem when the key differentiator is having domain experts (e.g., most
financial services companies make their money by having domain experts in
particular types of financial instruments that can write programs very
quickly to model the behavior of those instruments.)

Pair programming doesn't solve any of the enterprise issues because teams of
500 people over a 10 year lifespan of an enterprise project don't get to
pair with each other.  In fact less than 30% will be working for the company
at any given time.

Finally, the issue I raised was about third party modules mucking with the
behavior of my code.  Ruby encourages this.  Folks patch other people's
modules/classes all the time.  This is dangerous.  It means that every
single time I run gem update, I have to re-validate all my code.  This does
not lead to predictability in code execution.  This leads to disaster.

On 5/3/06, Leslie Viljoen <leslieviljoen / gmail.com> wrote:
>
> Thanks for the reply!
>
> On 5/3/06, Francis Cianfrocca <garbagecat10 / gmail.com> wrote:
> >
> >
> > Anyway I don't have the answers (yet) and there is a long way to go. But
> I
> > don't think Ruby should be "improved" to fit traditional large-system
> > methodology. I think the reverse (somehow) is closer to true.
>
>
>
> Perhaps something as dynamic as Ruby requires a team methodology as
> dynamic
> as XP. I think pair programming is (at least partially) intended to limit
> the damage
> caused by not-so-experienced programmers. Then the remaining problem
> would be trying to convince management that pair programming is actually
> worth
> it, and trying to convince programmers to put aside their egos to the
> extent
> where they all are willing to accept constant advice and input from a
> partner.
>
>


--
--------
David Pollak's Ruby Playground
http://dppruby.com

------art_44615_29486197.1146665141815--