OT about Extreme Programming

[Alain Farmer]

Hello Sadu and y'all,

>> I am not as rare as you might think. There are
>> a dozen+ new "agile" software development
>> methodologies being taught & used, like
>> "Extreme Programming" for ex, which argue
>> against too much documentation and

> Yap. We've tried it.

Have you really tried it ?

> Some of it is good, some not so good.

I am not saying that XP is all or nothing proposition,
but their practices support each other synergetically.
Removing one or more of the practices is likely to
make the process hazardous.

> Actually having someone (old hand) sit there while
> someone else codes (newbie), and they watch over
> their shoulder? REVOLT.

No offense intended, but this is a 'naive'
(uninformed) reaction that many people express when
they first get wind of "Pair Programming". It's much
more than what you describe above. For one thing, the
roles are switched frequently within any given
session. The partners are often switched too, thereby
exposing all the members of the team to each-and-every
member of the team, and therefore learning the style,
technique and domain of every member of the team. If
someone leaves, the XP team can easily pick up the
slack, because the person's knowledge has been shared
all along with every member of the team (or at least
some of them). Contrast this with the "specialist"
approach. When he leaves, the non-XP team has to
scramble [vainly] to find someone as specialized and
up-to-speed with the project.

Let's get back to the roles now. One of the pair is
coding (detail oriented) while the other is focused on
systemic issues like how this fits in with the rest,
whether the coding standard is being respected, etc.
It is a *team* effort. While one thinks, the other one
does. Ideas being exchanged. Two heads are better than
one; and when they work *well* together two heads are
better than two, e.g. the whole is greater than the
sum of its parts.

> That part of XP I could not agree with.

I must admit that Pair Programming is one of the more
controversial practices of XP.

> I could strongly agree with other parts, such as
> do the simplest thing that actually works.

And you don't do this just once, eh!  You continuously
refactor your code such that it always does the
simplest thing that actually works. Complexity
attempts to creep in as changes are made, but
merciless refactoring keeps everything as simple as it
can be. You start out simple, e.g. no "Big Design UP
Front", and you evolve the design of the program for
the needs you encounter, instead of trying to
anticipate things that may never be needed. In this
regard, refactoring is also a *design* task.

> I could strongly agree with other parts...

Apart from Pair Programming, which practice(s) do you
disagree with? What do you think of "Test First", for
instance. With these automated tests, you can always
KNOW whether a change you make breaks the system, by
testing it, rather than relying on your memory or your
ability to infer all consequences. These tests
therefore protect the project from bugs and, following
up on my bit about the "synergy" of their practices,
"Test First" allows any member of the team to make any
change of any scope at any time in the project. You
can even make very radical changes near release time.
Or make changes much later on, when the original team
is no longer intact for instance, because the tests
are still there to flag the bug the newbies might
attempt to introduce. Imagine what this means in terms
of flexibility! BTW, that's why Kent Beck's
introduction to Extreme Programming is subtitled
"Embrace Change", e.g. not just *adapt* to it as best
you can, but *embracing* it!

> Rapid prototypeing, rapid interations, create the
> specs as you go so to speak - that works pretty
> darn well for some things.

Granted that Extreme Programming is not appropriate
for any/all software projects, but there are other
"Agile" methodologies (some of them created by Kent
Beck) which address the issues that XP does not.
Scaling up, for ex, to HUGE projects, etc.

> Again, it depends on scale and scope.

Okay.

> For conservative organizations that expect the code
> to last a long time .. mmmmm..XP?. maybe not...

What do you think now that I have discussed tests and
refactoring and pair programming ?

> ... but for dot-coms that have to react quick...

Agile methodologies were specifically designed to be
more nimble, flexible, change-embracing, etc.

> ... and could come and go rapidly, and who cares
> if no one but the authors understand the code...

Turnover is a problem, but it is much prevalent among
XP teams because of their concerted efforts to
re-emphasize the importance of communication, a
sustainable pace, in a pleasant work environment where
colleagues genuinely listen to each other and engage
in dialogues/work that is enobling to the spirit.

> you sell it off and let the buyer beware
> of the code without the comments.

Face with the alternative of [parsimonious] comments
versus automated tests, I would choose the tests. I
would then do my best by interpreting the code & the
tests, which have been continuously refactored into a
simple-as-can-be program which is self-explanatory 
because it adheres to a well-defined coding standard.

>> In essence, you should be as parsimonious as you
>> can be with your comments, relying instead on the
>> dev's group abilities, the quality of their
>> communication ...

> Nope. You have to factor in the average career of
> an IT guy is about 2 years in one organization
> before they move on.

But they don't move on all at once. If the XP team is
solid, fewer team members will leave [abruptly]. When
they do leave, the XP team has not lost a "specialist"
that cannot be replaced, e.g. pair programming spreads
knowledge and skills around. If the XP team adds new
members as old ones leave, at a sustainable pace, then
the entity "team" will survive even if all the
original members have ultimately left the team.

BTW : *All* of the cells in our body are replaced
every two years or so, and yet we live a whole
lifetime with the belief that we are ourselves. The
'entity' survives the replacement of all of its
components.

> Management MUST insulate themselves
> from this kind of turn over.

Are comments the answer?

> Yeah, it would be fine to rely on this if you
> could chain them down and get lifetime guarantees.

This is not necessary to make XP viable.

> Hey, and I told the board of directors "well,
> I was relying on them being here forever so we
> didn't need commented code" .. ha ha!  that'd
> be my sweet akole on the line.

Commenting and documentation tend to be ways in which
we conservativelky protect/shield ourselves from the
risks and responsibilites of making it happen. If we
fail, we can always justify our actions to our
superiors, and to our peers, and therefore deflect
blame for things gone bad. It's, in fact, the same
perverse logic that makes most enterprises behave like
the other guys (conformity) and, not surprisingly,
find themselves in the same boat (good and bad).

> Again, if you are a one man or small shop, no
> plans for making an establishment to last
> generation after generation, hey, no problem

The team-building aspects of XP make for a strong
establishment that is likely to outlast most outfits
that don't attend to the critically-important human
factors. As for software, I've shown how/why XP teams
can persist through time, and thereby maintain the
code developed by the inaugurators. OTOH do you really
expect your software to last several generations?

> if you are in the corporate world of megafinance
> and gotta be conservative, its a different story.

It's unquestionably true that the corporate world of
megafinance is conservative and demands all kinds of
paperwork to make them feel secure about their [short
term] investment, but it does not follow that this is
the best methodology for creating great software.

> Actually in our shop, we have some of each side
> of the coin, because, the mind of man is meant
> to create, and we have to allow that too, with
> a certain freedom, and agility, to remain
> innovative and proactive.

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

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com