Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Extreme Programming

 
Dale DeMott
Ranch Hand
Posts: 515
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tell me what you think...
Define Extreme Programming in your own words what it means to you.
Define Pair Programming in your own words what it means to you.
Does Pair Programming work if one person is advanced and the other person is just starting out with Java.
Thanks for your responses!
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This should probably be moved to the process forum, but anyway...
Define Extreme Programming in your own words what it means to you.

Not my own words, but the ones of Ronald E. Jeffries:
"Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation."

Define Pair Programming in your own words what it means to you.

It's two programmers working as equal partners on one computer. It's also the most effective and joyfull form of working I know!

Does Pair Programming work if one person is advanced and the other person is just starting out with Java.

Generally, yes. It's a matter of personality, not of knowledge. Take a look at http://www.xprogramming.com/xpmag/pairing.htm
 
Jessica Sant
Sheriff
Posts: 4313
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
... seems oddly like homework....
 
Dale DeMott
Ranch Hand
Posts: 515
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm only wondering because some groups I know are using it and I'm not sure they are using it correctly. I honestly didn't want to say anything to sway anyone's idea of what they thought it was. More replies are welcome.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Dale DeMott:
I'm only wondering because some groups I know are using it and I'm not sure they are using it correctly.

Interesting, tell us more, please! What are your doubts?
 
Dale DeMott
Ranch Hand
Posts: 515
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I guess my thoughts are this...
Lets assume the project being programmed is on a tight deadline.. and pair programming is going on at all the terminals. The advanced people are basically driving... the junior programmers are trying to follow along... the tough thing about this is that the junior programmers are going to need support this after the advanced programmers leave. And they will leave... Seems to be it doesn't work in this case.
Thoughts???
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Dale DeMott:
Lets assume the project being programmed is on a tight deadline.. and pair programming is going on at all the terminals. The advanced people are basically driving... the junior programmers are trying to follow along... the tough thing about this is that the junior programmers are going to need support this after the advanced programmers leave. And they will leave... Seems to be it doesn't work in this case.
Thoughts???

Let the juniors drive most of the time. For this you need some mature seniours, admitting that the juniors *need* to learn, willing to mentor them and open to learn from the juniors as well.
And don't enforce junior-senior pairing for all the time. Let them relieve stress by tolerating other forms of working. Just encourage mentoring, with a mature team the rest will work out. With an immature team, you are doomed anyway...
 
Junilu Lacar
Bartender
Posts: 7483
50
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Making the juniors drive most of the time can be a tough proposition to carry out and can be made even more difficult under schedule pressure. You need very patient seniors who understand that their role is to mentor and make sure that the "theories" they have about the system are passed on correctly to the juniors. If seniors don't have the patience, it will be next to impossible to make pairing work and could easily degenerate to seniors merely dazzling and/or befuddling the juniors.
As Ilja said, try to rotate the pairs often to provide variation and a good spread of knowledge. Try to identify the pairs that get along better and make them work together more often while keeping the disfunctional pairs apart (but give them a few rotations to try to adjust).
HTH,
Junilu
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Junilu Lacar:
Making the juniors drive most of the time can be a tough proposition to carry out and can be made even more difficult under schedule pressure.

Schedule pressure always is a bad thing. There are surveys showing that schedule pressure drastically decreases the effectiveness of software development teams. (I think I read in Peopleware about it.)
You need very patient seniors who understand that their role is to mentor and make sure that the "theories" they have about the system are passed on correctly to the juniors. If seniors don't have the patience, it will be next to impossible to make pairing work and could easily degenerate to seniors merely dazzling and/or befuddling the juniors.

Possibly this can happen, yes. In this case, I don't see how you would avert the danger of being doomed right after the the seniors left, though

As Ilja said, try to rotate the pairs often to provide variation and a good spread of knowledge. Try to identify the pairs that get along better and make them work together more often while keeping the disfunctional pairs apart (but give them a few rotations to try to adjust).

I can't remember saying that...
In fact, I wouldn't force rotation on them. Generally pairs are expected to form as needed, not to be assigned. They will probably just self-organize in a way you couldn't have planned better.
You *might* want to encourage more switching if you don't see enough. Again, don't enforce it, just discuss with them what you are observing and try to come to a solution the whole team can aggree on.
Holding retrospectives regularly might be a good idea. Discuss what worked well and what didn't work. End a retrospective by short lists of "do again"s, "never do again"s and "try for the next week(s)"s.
In other words: Let the team know the priorities of the project, let them reflect on how they are doing and let them decide what they want to do about it.
[ May 31, 2002: Message edited by: Ilja Preuss ]
 
Junilu Lacar
Bartender
Posts: 7483
50
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I can't remember saying that...
In fact, I wouldn't force rotation on them... You *might* want to encourage more switching if you don't see enough. Again, don't enforce it...

Sorry for putting my interpretation of what you wrote in your mouth...
Yes, you're absolutely right. Managers, despite their good intentions, often try to control things too much and end up hindering rather than facilitating.
 
Jessica Sant
Sheriff
Posts: 4313
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here in HP Middleware we've adopted a semi-XP approach. I'm most familiar with the idea of writing tests first (JUnit/HTTPUnit), then writing the code 2nd. It's sorta tought to get yourself to do it at first... but VERY effective. And you develop a regression testing suite along the way.
I work in the Current Product Engineering group (we fix bugs in and add enhancements to the current product). So the Test-First scheme is ideal -- you create a test that shows the bug (by failing) and then code til the test passes. Add it to the suite so you're guaranteed the bug won't come back. Very slick.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic