What is Java extreme programming?

[John Gagon]

One fairly good way to do that is to go read the
discussion in online browser-accessible archive
http://groups.google.com/group/comp.lang.java.programmer
Once there, pick out the discussion thread by title,
click the "show as tree" link, then in the left
sidebar, click the "sort by date" link.

This is good advice....for probably many others besides myself. ;-)
I've been using Google Groups since it was assimilated from being
Deja. (and in fact, the tree is my preferred layout).

Sorry, I was just indicating that I haven't had time yet. I have now
and humorously enough, the one just above me even uses similar
lingo. Pardon _that_ faux pas. (sp?).

In addition to google groups, there are quite a few other content
scrapers out there who either trawl google groups or usenet (ie: esp
the
comp.lang groups etc etc) probably in hopes for generated duplicate
searchable content for more ad clicks or something.

You can then
click down the left side and read the OP and replies
in time sequence, which is probably a lot better
than threaded sequence, since people will often
adopt ideas from several branches of the thread, but
use them in only one posting, and expect you, too,
to have the ideas from all those branches they have
read simultaneously within your recall as "context"
with which to understand their writing.

HTH

Thanks. It has in perhaps ways other than you anticipated.

John Gagon

 

[John Gagon]

Here's an interesting perspective on extreme programming:

http://www.hacknot.info/hacknot/action/showEntry?eid=11

It seems to me that methodologies in general (and *gasp* even
languages) can have cult followings. Most people seem to pick and
choose rather than whole heartedly subscribe to a methodology. There
are benefits though to doing each.

Picking and choosing often means picking and choosing from several
different "trees of fruit" or ideology. Such people often create their
own "best practices" instead or even choose strategies for each part of
a problem rather than apply methodology X because it best suits the
main problem. A loose collection of strategies in a kind of toolbox
seems more flexible and handy and sometimes faster.

Using a methodology can sometimes have inter-relational or
standardization types of benefits as well as simplifying and unifying
an approach that other teams can use and continue.

My preference leans towards doing a collection of strategies. ie: a
type of scheduling well suited to the complexity, ensuring a particular
set of necessary systems are in place where needed. Combatting
particular problems endemic to an environment. i.e.: low developer
focus might be helped by temporarily pair programming or requiring the
use of a log or using a little more micromanagement (sometimes, total
hands off management is deadly to a project) or allow them to do short
easy turnaround tasks to keep pace and confidence up. But I wouldn't be
closed to adopting a methodology if it were consistently adhered to and
shown to be both natural as well as productive or increasing needed
communication in areas it might be meant to.

John Gagon