From: "Kurt Kuzba" 


From: Bruce D. Wedding
Subject: [C] Extreme Programming
BW>  So, any of you guys heard of it, practiced it?  What do you
BW>  think?  I think there are some very good ideas in there but
BW>  some of it just seems impractical.  If you don't know what it
BW>  is, here are the fundamental tenets:
    This sounds like a corporate strategy to maximize a product's
 time in use on the front end.  Rather than finish it and then find
 bugs in the field, release it in beta and use the power of the
 random user to illuminate the problem areas.

BW>  1.  Planning - Prioritize the next release by combining
BW>  business priorities with technical estimates.  Basically,
BW>  perform the changes in priority order.
    Give the customers what they want and need first.

BW>  2.  Small Releases - Release new versions constantly,
BW>  build everyday.
    Don't keep the customer waiting.  Respond immediately.

BW>  3.  Testing - Continuous unit testing.  Tests are written as
BW>  code is written.  Customers write and run feature tests.  An
BW>  integration test must be run at each build.
    Take nothing for granted.  Thoroughly test every edit.

BW>  4.  Refactoring - Continuous refactoring.  Simplify, remove
BW>  duplication, add flexibility.
    Keep it simple.

BW>  5.  Pair Programming - production code is written with 2
BW>  programmers at each machine.
    Redundancy and error checking on an ongoing basis.

BW>  6.  Collective ownership - anyone can change any part of the
BW>  code.
    Results have the final say, not the programmers.

BW>  7.  Continuous Integrations- integrate and build many times
BW>  a day.
    Nobody gets to drift out of the project.  It works, period.

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

BW>  9.  On site customer - A real user, whatever that is, on site
BW>  all the time
    If you don't know what the customer wants, ask.  No guessing.

BW>  10. coding standards - All write according to rules emphasizing
BW>  communication through code.
    Code is self-documenting and everybody can read and understand.

BW>  OK, in a nutshell, I like it.  I can see how it would have
BW>  helped many of the large projects I've worked on.  The one I
BW>  have an issue with is pair programming.  I did it once when I
BW>  had no choice for 4 months and I hated it.  Of course, it may
BW>  have been the person I was working with but I'm reluctant to
BW>  try again.  In pairs, people have to be flixible and willing to
BW>  listen.  My partner was not.  It was HER way or else she'd throw
BW>  a fit or just ignore you and do it her way anyway.
BW>  So, what do you all think?
    Your partner ignored a few of the rules.  That's where we get
 stuck on learning plateaus.  If you can't be wrong, you can't go
 any further in getting it right.  Einstein doesn't nullify Newton,
 but Newton doesn't delve so deep as Einstein.  It all seems pretty
 solid, though I prefer to putter about on my own.  It sort of looks
 like the formula used for Fido collaborations in the old days, when
 they would throw a raw idea into the tumbler and pull forth a gem.
 It looks like they are learning from the open source community.
 Open source projects are usually back burner, though, so this is
 tightened up to fit a commercial model.

>  kkuzba{at}centurytel.net   http://home.centurytel.net/kkuzba
>  We work with being, but non-being is what we use. (Tao te Ching #11)

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