From: "Bruce D. Wedding" 

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.
6.  Collective ownership - anyone can change any part of the code. 7. 
Continuous Integrations- integrate and build many times a day. 8.  40 hour
week - No overtime or very limited overtime 9.  On site customer - A real
user, whatever that is, on site all the time 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?

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