What is Java extreme programming?

C

Chris Uppal

Chris said:
This is a discussion forum.

One significant advantage of which, when compared to essentially static web
pages, is that posts are subject to public peer review and debate.

(And just don't get me started on "blogs" -- I suspect that some here are
closet bloggers and I might easily cause offence)

-- chris
 
A

Andrew McDonagh

Chris said:
One significant advantage of which, when compared to essentially static web
pages, is that posts are subject to public peer review and debate.

(And just don't get me started on "blogs" -- I suspect that some here are
closet bloggers and I might easily cause offence)

-- chris

Yes please dont start on blogs.... what with me too, we'd never finish
pissing the bloggers off!
 
R

Roedy Green

One significant advantage of which, when compared to essentially static web
pages, is that posts are subject to public peer review and debate.

The biggest theoretical problem is the link can go away, or the
referenced text can change. With newsgroup postings you have a
permanent record of the precise debate. One if of the nicest features
of newsgroup debates as you can settle definitively charges of the
form "but you said...".

With the Agent browser, a link is much easier to deal with than
someone who quotes everything, relevant or not. Some of these debates
could melt away with technology to make referencing links faster and
if quoting were handled so attributions were automatic and you had
windows to control just how much volume you were prepared to look at
in a quote. For me, rarely is more than a few lines of a quote
needed to put the comment in context.
 
L

Luc The Perverse

Chris Uppal said:
One significant advantage of which, when compared to essentially static
web
pages, is that posts are subject to public peer review and debate.

(And just don't get me started on "blogs" -- I suspect that some here are
closet bloggers and I might easily cause offence)

What have you got against blogs?

I use blogs as a disorganized way to record things on my mind. My readers
find my blogs entertaining (although I would prefer if they found them
thought provoking)
 
L

Luc The Perverse

Roedy Green said:
For me, rarely is more than a few lines of a quote
needed to put the comment in context.

I agree. I check NGs at least daily - so it isn't like I have forgotten
what a discussion was about - I merely need a reminder.

Although I don't know how we got started talking about this ^^
 
J

Jeffrey H. Coffield

Roedy said:
I am not
asking for thanks, just laying off the generic barbs.

You may not be asking, but for myself, thank you.

Your examples have helped me many times and your input into
advancing usable knowledge is greatly appreciated.

Jeff Coffield
 
R

Roedy Green

The biggest theoretical problem is the link can go away, or the
referenced text can change. With newsgroup postings you have a
permanent record of the precise debate. One if of the nicest features
of newsgroup debates as you can settle definitively charges of the
form "but you said...".

The big advantage of a link is freshness. If I put information on a
web page I can correct, update, freshen at any time, and anyone
finding my post in groups.google.com linking to it will be taken to
the freshest information. If I had inserted the information inline,
they would get stale information. I may have even elsewhere repudiated
it utterly, but they would still see it as valid.
 
R

Roedy Green

I agree. I check NGs at least daily - so it isn't like I have forgotten
what a discussion was about - I merely need a reminder.

Although I don't know how we got started talking about this ^^

Chris was chastising me for using links. I then pointed out it
depends on your tool which is awkward, a link, excessive quoting,
attribution.
 
C

Chris Smith

Roedy Green said:
Chris was chastising me for using links. I then pointed out it
depends on your tool which is awkward, a link, excessive quoting,
attribution.

Me? I wasn't chastising you. I regret the misunderstanding, if what I
said was taken that way. I would prefer to see significant posts to the
newsgroup instead of links, but you are free to do what you like. I
merely pointed out that it's more likely the links, and not the partner
fees from online bookstores, that bother people. If you want to know
who was bothered, I'd suggest you look further up the thread.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
A

Andrew McDonagh

Chris said:
Me? I wasn't chastising you. I regret the misunderstanding, if what I
said was taken that way. I would prefer to see significant posts to the
newsgroup instead of links, but you are free to do what you like. I
merely pointed out that it's more likely the links, and not the partner
fees from online bookstores, that bother people. If you want to know
who was bothered, I'd suggest you look further up the thread.

Hands up...it was me that experienced annoyance of Roedy's link.

I wasn't offended by it - just annoyed.

I wasn't offended by the fact he posted a link to his site.

I wasn't offended by Roedy's reply.


However, I was annoyed that as an answer to the OPs question, Roedy
posted a link to his a PAGE of his site, where the page contained a very
short and mostly WRONG description of what XP is, plus one additional
link to http://www.extremeprogramming.org/

Aside from that, it contained a whole suite of links to various book shops.

So my point was, if thats all it contains, then it would be better to
simply post the http://www.extremeprogramming.org/ link instead or have
the page redirect the user to http://www.extremeprogramming.org/.

Roedy's site does contain a lot of useful info for newbies, no one,
including myself denies this. But pages like this damage his reputation
(at least in my eyes) as it comes across as being a money generating
link scheme instead of a useful resource.

Andrew
(Your favourite (psuedo) commie ;-) )
 
K

Kent Paul Dolan

Dave said:
Here's an interesting perspective on extreme programming:

Yes, that's quite a bit closer to my gut evaluation of XP, a
technology for those who cannot handle CMM level 3.

XP is great for one up, throwaway projects, I suppose, and
since that represents lots of software produced in the real
world, whether by intention or not, it has a place in the
software industry,

I cannot conceive, though, of accepting employment in a
situation where maintenance of code created by XP was
part of the workload.

xanthian.
 
A

Andrew McDonagh

Kent said:
Yes, that's quite a bit closer to my gut evaluation of XP, a
technology for those who cannot handle CMM level 3.

XP is great for one up, throwaway projects, I suppose, and
since that represents lots of software produced in the real
world, whether by intention or not, it has a place in the
software industry,



You should take a look at...

http://www.sei.cmu.edu/publications/articles/paulk/xp-from-a-cmm-perspective.html

It shows where and how XP matches against each level.

I cannot conceive, though, of accepting employment in a
situation where maintenance of code created by XP was
part of the workload.

xanthian.

Why? Code that is completely covered with automated Acceptance and Unit
tests is not good enough for your maintenance?

Not to mention the design docs that most teams will create if required.
 
K

Kent Paul Dolan

] Revisionism
Again, is it inherently evil?
Absolutely.

As an engineer, I have been taught to celebrate the principle of
step-wise refinement.

Sorry, that is not even close to what the quoted paper meant by
"revisionism". It detailed quite clearly the _intellectually dishonest_
citing as an example of the initial success of XP a project which
was, in fact, a flop.

The "revisionism" there is _historical revisionism_, rewriting
history to make it be the way you wish it had been, instead of
the way it was, to support come current agenda of yours,
something extremely popular in the Soviet Union in the days
of Joseph Stalin, something done long past by the then
Christian church to throw away all but a few of the existing
descriptions of the life of Christ, to retain only that set (as
"Gospels") that agreed with their then current politics.

Given that XP advocates need this kind of lying to attract and
retain adherents, I wouldn't have characterized XP as a cult,
but, even less favorably, as a religion.

FWIW

xanthian.
 
K

Kent Paul Dolan

John said:
I haven't been able to read all the replies so
maybe this was covered somewhere else.

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. 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

xanthian.
 
T

The Magpie

Kent said:
I cannot conceive, though, of accepting employment in a
situation where maintenance of code created by XP was
part of the workload.
Neither could I until we tried it at the firm I was working with. Our
productivity went up by almost 30%, bugs fell by over 60% and the rate
we could deal with fixes and updates just went clean through the roof.
Granted, there were issues - we were a relatively small team and so the
pair-coding caused some friction; the code review was always a little
tricky since I was the main reviewer and spent most of my time hopping
between pair-teams; and it took almost a year to get properly used to
test-building as we developed code.

Having done it once though, I would say that if you get the choice
between a job using XP and one not doing, go for XP.
 
K

Kent Paul Dolan

The said:
Kent Paul Dolan wrote:
Neither could I until we tried it at the firm I
was working with. Our productivity went up by
almost 30%, bugs fell by over 60% and the rate we
could deal with fixes and updates just went clean
through the roof.

None of which are related to the issues of coming
into a project which lacks an architecture document,
and spurns documentation as a waste of time, and
solves problems "in the small" and "as they come up"
rather than before they occur.

XP compared to CMM level 4 is sort of like the
difference between peephole optimization and global
optimization in a compiler. Both "work", but one is
a whole lot more powerful in controlling the shape
of the final product, because it has a broader
perspective from the start.
Granted, there were issues - we were a relatively
small team and so the pair-coding caused some
friction; the code review was always a little
tricky since I was the main reviewer and spent
most of my time hopping between pair-teams;

That's broken. Reviewers _should_ be other peers,
not some superprogrammer. Code review is a great way
to develop code reading and writing skills in all
participants, the experience shouldn't be tailored
to use only the most competent and leave out the
newbies as reviewers, who could most use the
education and the familiarization with the rest of the
code.
and it took almost a year to get properly used to
test-building as we developed code.

This, on the other hand, should have taken about
five minutes: "write the test, then the code it
tests" isn't a difficult meme if they have to be
delivered in that order.
Having done it once though, I would say that if
you get the choice between a job using XP and one
not doing, go for XP.

No, thank you.

I lasted about three months in my last job,
precisely because my employers couldn't be bothered
to decide in advance what they wanted me to do
before it was begun. In that period, they changed
the projects' specs roughly daily, often with "start
over from scratch" effects, and I could only deliver
prototypes, never something that fully satisfied
their current thinking, in that entire time period.

That they also took some college student's
"framework" project from a grad school class, one
that ignored most modern thinking on how complex,
frequently redefined interfaces should be done (in
robust XML streams, not in fragile parameter by
parameter passing), as their be all and end all
project architecture, and refused all pleas for
changes to it, didn't help a bit.

Compare this to my happy, productive experience in a
CMM level 3 shop, where projects occasionally
slipped schedule a bit, but arrived fully compliant
with specs and embedded in a well-thought out
architecture that worked end to end. Of course, we
were dealing in a project whose budget was dollars
in thousands of millions, not thousands (Motorola's
IRIDIUM), and in code bases of hundreds of millions
of lines, not tens of thousands of lines, so no one
was going to "own all the code", thus XP was never
even a consideration.

FWIW

xanthian, not a fan of "agile programming".
 
R

Roedy Green

None of which are related to the issues of coming
into a project which lacks an architecture document,

I think that really depends on your problem. Some problems you can
specify in every last detail to start. Others you don't really even
know what the problem is yet. You need some experience before you can
even see what might be possible.

Something like a mortgage loan system would be of type 1. Something
like developing Eclipse would be of type 2.
 
A

Andrew McDonagh

Kent said:
None of which are related to the issues of coming
into a project which lacks an architecture document,
and spurns documentation as a waste of time, and
solves problems "in the small" and "as they come up"
rather than before they occur.

Agile methodologies (XP, Scrum etc) all value documentation. None spurns
them as 'a waste of time'

Indeed the Agile Manifesto actual says:

"Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

That is, while there is value in the items on
the right, we value the items on the left more."

What XP says, like the other agile methodologies, is that some documents
have been found to be of less value than others and so tend not be be
created or are created later in the project life cycle.

XP does NOT say you cant have them, it simply says, 'Here is the cost of
them' If that cost is ok for the team and the various types of
Customers then they are created and maintained. If they are not deemed
worthwhile or too expensive then they wont be.

Lots of XP teams will create a broad architecture and various other
documents. They tend to create them nearer the end of the projects,
usually just before the project is moved into a maintenance phase. For
the same reasons other methodologies create them - Communication.

They tend not to create them at the beginning, because they simply
aren't needed by the team. This does NOT mean the team starts out
creating a system without any idea of what architecture to use.

All XP teams spend an amount of time at the beginning working through
the various architectural approaches they might take, before deciding
upon one. Once decided, they will certainly, only implement enough of
it for the features they are working upon at that time.

We call this time 'Iteration Zero'.

In practice, its very rare for the fundamentals of the architecture to
change during the project, even when we only implement those parts that
we need today. Some parts may change, but the overall architecture
doesn't, but then this happens even in other methodologies.
XP compared to CMM level 4 is sort of like the
difference between peephole optimization and global
optimization in a compiler. Both "work", but one is
a whole lot more powerful in controlling the shape
of the final product, because it has a broader
perspective from the start.


That's broken. Reviewers _should_ be other peers,
not some superprogrammer. Code review is a great way
to develop code reading and writing skills in all
participants, the experience shouldn't be tailored
to use only the most competent and leave out the
newbies as reviewers, who could most use the
education and the familiarization with the rest of the
code.


This, on the other hand, should have taken about
five minutes: "write the test, then the code it
tests" isn't a difficult meme if they have to be
delivered in that order.

The 3 Steps of TDD '1) Write one failing test, 2) Make the test pass,
3) Refactor' shouldn't be too hard to grasp. However, it typically is.

Just about every developer I've coached TDD to, always creates the class
and its skeleton before the filling in the testcase. They have done it
that way for soooo long they find it hard to do otherwise. Even simple
things like intellisense gets them. With the first test, there is no
class so the intellisense doesn't work - it totally screws them.

I personally have no idea why - but it does for most.

Aside from the mechanics though, the biggest challenge is making the
mental shift required to get the most out of TDD.

It can easily take a month, two or more before people have the 'a-ha'
moment when they are TDDing. The simple things like approriate testcase
names for example. I interviewed a developer last month who had been
TDDing for 6 months - great I thought - someone who should be
experienced enough to join the team without much coaching.

However his test cases were called

class TestRomanNumeralGenerator extends testcase {
testSimple1() {...}
testSimple2() {...}
testSimple3() {...}
testMultiple() {...}
testException() {...}
}


These are useless as testcase names as they do NOT reveal anything about
what the design is.

During the interview we went through them and he changed them to be more
Behavior and/or Specification revealing....

class TestRomanNumeralGenerator extends testcase {
testRomanNumeralRepresentationsForIntegersOneToNine() {...}
testRomanNumeralRepresentationsForIntegersBetween10And99(){..}
testRomanNumeralRepresentationsForIntegersBetween100And3999(){...}
testExceptionThrownAsZeroIsNotValidRomanNumber() {...}
}

These aren't brilliant, but they are a hell of a lot clearer than the
initial set.

TDD is design process which uses Unit tests to capture and document the
behavior/specification - there's even a project ongoing now where people
are creating new frameworks that use the words 'Behaviour' or
'Specification' instead of 'Test' or 'unit test' as they feel it
correctly shows what is meant by TDD.

No, thank you.

I lasted about three months in my last job,
precisely because my employers couldn't be bothered
to decide in advance what they wanted me to do
before it was begun. In that period, they changed
the projects' specs roughly daily, often with "start
over from scratch" effects, and I could only deliver
prototypes, never something that fully satisfied
their current thinking, in that entire time period.

That they also took some college student's
"framework" project from a grad school class, one
that ignored most modern thinking on how complex,
frequently redefined interfaces should be done (in
robust XML streams, not in fragile parameter by
parameter passing), as their be all and end all
project architecture, and refused all pleas for
changes to it, didn't help a bit.

XP projects certainly do NOT run like this.

Yes this sounds like a nightmare - were they trying to do XP here or was
it more of the case that they simply didn't know what they wanted? or both?

Either way, regardless of the methodology used, this project would be
doomed.
Compare this to my happy, productive experience in a
CMM level 3 shop, where projects occasionally
slipped schedule a bit, but arrived fully compliant
with specs and embedded in a well-thought out
architecture that worked end to end. Of course, we
were dealing in a project whose budget was dollars
in thousands of millions, not thousands (Motorola's
IRIDIUM), and in code bases of hundreds of millions
of lines, not tens of thousands of lines, so no one
was going to "own all the code", thus XP was never
even a consideration.

For projects of that size, vanilla XP wouldn't be a good choice.

There are some supplemental practices that could be used to facilitate
this size (see industrialXP for those) or my preference, use a different
Agile methodology - Scrum for instance. Scrum can scale to this size
out of the box, because you can have scrums of scrums (Teams of Teams
working upon their own part of the feature list).
FWIW

xanthian, not a fan of "agile programming".

Andrew

FWIW, not a fan of poo-pooing things I haven't used.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,582
Members
45,065
Latest member
OrderGreenAcreCBD

Latest Threads

Top