From: "Roger Scudder" 

-----Original Message-----
From: c-bounces{at}snippets.org [mailto:c-bounces{at}snippets.org] On Behalf
Of Bruce D. Wedding
Sent: Monday, April 26, 2004 12:21 AM To: c{at}snippets.org
Subject: [C] Extreme Programming

> So, any of you guys heard of it, practiced it?  What do you think?  I
think there
> are some very good ideas in there but some of it just seems
impractical.  If you
> don't  know what it is, here are the fundamental tenets:

> 1.  Planning - Prioritize the next release by combining business
priorities with
>     technical estimates.  Basically, perform the changes in priority
order.

> 2.  Small Releases - Release new versions constantly, build everyday.

> 3.  Testing - Continuous unit testing.  Tests are written as code is
written.
>     Customers write and run feature tests.  An integration test must
be run at each
>     build.

> 4.  Refactoring - Continuous refactoring.  Simplify, remove
duplication, add
>     flexibility.

> 5.  Pair Programming - production code is written with 2 programmers
at each machine.

I think this is the thing that kills it for most people.  I can only see it
working in very specific situations.  Both participants must respect each
other and be willing to put their egos aside.  In general, I think paring
should be optional.

> 6.  Collective ownership - anyone can change any part of the code.

Whoa!  This one really defies conventional wisdom.  Maybe in very small
team environments, but I in general I don't think it is a good idea.

> 7.  Continuous Integrations- integrate and build many times a day.

> 8.  40 hour week - No overtime or very limited overtime

I like it.  This is how it should be if scheduling it done correctly and
everyone does their job.

> 9.  On site customer - A real user, whatever that is, on site all the
time

It makes sense if they are able to contribute in some way, say as a domain
expert or tester.

> 10. coding standards - All write according to rules emphasizing
communication
> through code.

> OK, in a nutshell, I like it.  I can see how it would have helped many
of the large
> projects I've worked on.  The one I have an issue with is pair
programming.  I did it
> once when I had no choice for 4 months and I hated it.  Of course, it
may have been the
> person I was working with but I'm reluctant to try again.  In pairs,
people have to be
> flixible and willing to listen.  My partner was not.  It was HER way
or else she'd
> throw a fit or just ignore you and do it her way anyway.

> So, what do you all think?

As a whole I don't like it.  I think the ideas of using short cycles with
frequent builds and testing is on the money.  These ideas are, of course,
not unique to XP.

-Roger

--- BBBS/LiI v4.01 Flag-5