Subj : Re: extreme programming (thoughts)
To   : comp.programming
From : Phlip
Date : Thu Jul 21 2005 11:19 pm

matt wrote:

> > Pairing is more efficient than training newbies offline, catching
> > bugs in QA, designing on paper, etc. all totalled together.
>
> well.. hate to say it but if that were so clearly the case, we wouldnt
> be having this discussion, would we? :)

Okay. XP is a set of simple rules that attempt to fit _together_. If one of
the rules isn't working, you can't blame the rule if you are not doing the
rules that are supposed to support it.

(BTW "rule" is a four-letter word around here. Sed "principle" in
everywhere. Sheesh...)

When the Pairing rule falls down (I don't like pairing because my partner is
bored and I'm just typing the same stuff over and over again), look to the
Refactoring rules and the Acceptance Test rules. _They_ are the ones y'all
need to work harder on.

> in the history of programming,
> this has not yet be proven to be the case. subscribing to darwinist
> economics, this will surely be proven, if true.

Nothing is "proven". I can only apologies that you have not seen a "real" XP
team in action. Everyone working quietly for <7 hours a day, typing very
small amounts, releasing a whole new version every quarter, and _no_bugs_ in
the bugbase.

Your project sounds like a mosh-pit in comparison.

> personally, i think it
> will only be cost-effective if we offshore it to people already working
> for a third the price of US domestic IT workers, which certainly may be
> the trend.

Blah blah blah. I want to blame either Alan Greenspan or my dog, okay? ;-)

> > Prevention is better than a cure
>
> you will never eliminate debugging. as long as humans are flawed, code
> will be flawed. as will test cases, and other unforseen circumstances.

We test-first _because_ we are flawed.

Pleeeeeeze read this:

    http://flea.sourceforge.net/TDD_in_a_nut_shell.pdf

Others learning TDD have reported it was very helpful.

If its cycle does not sound familiar, then you have not yet experienced
"real" TDD, and hence must still debug.

> to me, the key is finding *balance*, a trade-off between extreme unit
> testing, and reasonable error-handling w/ logging.

Uh, different topic. Why no error-handling or logging? Of _course_ you need
that stuff. You should test-first it in!

-- 
  Phlip
  http://www.c2.com/cgi/wiki?ZeekLand

.