How many of you are Extreme Programmers?

[Christopher Blunck]

Robin Becker <robin at jessikat.fsnet.co.uk> wrote in message news:<XiCE$IAjFmn+Ew43 at jessikat.fsnet.co.uk>...
> I get the impression that XP is intended as a design none/test all
> process where the code some grows organically into the requirement
> through bursts of coding and testing. It even seems as though the
> testing is primary.

XP definitely does not discount design, it just puts a slightly
different spin on design.  Let's simplify project development into two
categories:  design (D) and implementation (I).  Implementation
actually consists of coding, testing, documentation, etc.  Design
consists of requirements gathering, scoping, planning, and ...
designing.

The way that I illustrate the difference between XP and other
practices is to plot design and implementation activities with respect
to time.  Time grows as you move to the right:

Traditional:   DDDDDDDDDDDDDDDDDDDDIIIIIIIDIIIIIIIIIIIIIDIIIIIIIIIDIIIII
XP:            DDIIIDIIDIIIDDIIDIDDDIDIIDDIIIIIDDIDIIDIIDIIDIIDIIDIDIDII

I probably have not a very good job in my diagram, but in the end, an
XP guy may spend as much time designing as a traditional developer
(maybe not), but because the design and implementation are comingled
you (the manager or the developer or the customer), have much more
granular control over the evolution process.

Traditional methodologies try to pin down unknowns, and seek to
eliminate risk by making an upfront investment in design.  But this
behavior in and of itself creates risk:  you delay implementation
until you feel your design is sufficient, possibly eating into time
you'll need later on for testing, documentation, and oh ya I forgot -
development.  :)

One aspect of XP is postponement of decisions until they actually need
to be made.  That's not to say that we're flying by the seats of our
pants.  We just recognize that often "the passage of time" is often a
much better means by which unknowns can be solved.  An unknown is
identified early, and everyone scratches their heads and says 'Ya -
I'm not very clear on that....'.  The traditional crowd then huddles
into a room and tries to gather requirements, design it, talk about
it, and ultimately build it.  The XPers say 'Let's think about it, and
come back to it later when we have some time.'  During that time the
XPers run a  thread in the back of their head to process the unknown. 
Emails get sent out, the customer is talked to, time goes by.  Maybe
the requirement or source of the unknown goes away, or changes into
something completely different.  Or, as is often the case, the unknown
solidifies and the team has a much better understanding of the
requirement.  This can happen quite often, actually.

It's funny how traditional thinkers accuse XPers of trying to "jump
into the code too quickly", when a lot of time we actually forego
decision making until such time that it is really necessary.  I can
see an argument for a slightly different statement being made about
traditional programmers:  they "jump into UML too quickly".


> Can XP be reduced to choosing candidates from the pool of programs that
> best satisfy a set of tests? If so experience from GP suggests that the
> tests require care to avoid common pitfalls. As an example a program
> might complete all the tests perfectly, but fail on all other instances
> of data (this commonly happens to overspecialised solutions).

That's very true.  And is why testing is such an important aspect of
development.  Testing is just a safety net that hangs below you. 
Having a safety net is important, but if the net is 200 ft. below you,
you're going to croak when you fall.  The more hard coded (and thus
fragile) your unit tests
are, the lower you place the safety net.  Eventually it can get to a
point where one says 'why even have a safety net?'



> Do XPers combine differing solutions etc etc?

I've always found XP minded people to be extremely open minded, and
willing to try different solutions to see if they'll work.  I can't
say the same for my traditional colleaques.  They are extremely close
minded, skeptical of anything other than what they know (this
permeates everything:  languages, testing practices, frequency of
integration, etc), and very confrontational.

It's sort of like the irony that is Windows vs Linux:  Most people
that criticize Linux have never used Linux.  Most people that
criticize Windows have used Windows and have switched to Linux. 
Likewise, most people that criticize XP have never used XP. 
Similarly, most people that use XP have come from traditional worlds
and have moved on to something better.

Ok that was a generalization.  ;)


-c