OT about Extreme Programming (Alain Farmer)

[Sadhunathan Nadesan]

| 
| I am glad to hear it. Please note that much of what I
| said here is *general information* that's not intended
| to criticize *you*, but rather to raise some important
| points for everyone to consider.
| 
| Thank you for listening,
| 
| Alain Farmer



Hi Alain,

You make some very good points and I suspect we are closer in agreement
that it may seem.  If I may start by saying your thoughts are well
taken and should probably deserve a specific answer for each point,
but perhaps you will forgive an abbreviated response.  I can tell you
are very passionate about the subject and very knowledgeable too, and
I respect that.  I can only speak from experience, really.

I'm working this weekend following up on a pairs-programming effort,
where the request came in late Friday.  One of my senior engineers/program
manager came into my office saying that an attorney was sitting in the
office of a VP at our corporate HQ, needing some statistics right NOW
for a class action law suit in progress, and my manager didn't have
enough background info to do it alone, plus he thought coding it in C
(his forte`) would take way too long.  We sat down together to do it
as a team in 4GL.  We had results within an hour but then of course the
users (who didn't really know what they wanted until they saw delivered
what they had asked for), realized that and made additional requests,
and consequently, we all are in touch by email and phone working over
the weekend.  Everthing has to be done by Monday morning.

We started with very little spec, refined it by prototyping, and had one
guy coding (me actually) and one guy watching in the same room, but now
of course are a virtual team.  In other words this has some elements of
XP but was basically forced on us by circumstance.  In this case we don't
care too much what the code looks like as long as the results are correct
because it's a one time effort (ha!  never say never; they may come back
with more requests, who knows), but anyway, it certainly has no comments!
(maybe one or two) and we haven't bothered much with beautiful formatting.
(Normally one of our pervasive practices is that code must be beautiful
on the inside as well as outside).   Anyway, I seriously doubt we will
go back and simplify and rework it over and over.  We will preserve the
work however.  And I have to continue with that now.

So, I gotta go.

But in kinda summary I would say that I agree with many of the things
you said; still, we do it differently.   Any theory has to in practice
adapt to the situation, I believe you agree with that?

I found a team approach is good, but not a two person team .. two people
can disagree and what is the resolution?  We use three.  Three is a
stronger structure in nature too, like a triangle.  I find we are more
likely to get consensus that way.   We have one 'analyst' overview
person, one coding person, and one qa/testing/documentation person.
All are actually software engineers and depending on the task, they all
rotate through these 3 positions.  But they don't sit in the same room
at least all the time while working on a project, they get together from
time to time.  In my shop there are no cubicles, everyone has a private
office, where they can shut the door if they want, and turn off the
phone if they want.  I have 3 employees who left once upon a time and
then later were hired back, they found out the grass was not so greener.
I have a couple of guys who back more than 18 years.  So I think I've
got an environment that is working pretty well, and I hope they are all
with me their entire career. I think they all agree that the better specs
they can get up front, the less recoding they have to do, but sometimes
the only way to get the specs is do the coding.

It's like a cartoon on my door.  A program manager is just leaving,
standing in the doorway of a room full of programmers in cubicles and
he is saying to them "You guys start coding, and I'll go find out what
they want".  So true, sometimes.

Later,

Sadhu