wood burning stoves 2.0*
The moose likes Agile and Other Processes and the fly likes Extreme Programming Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Extreme Programming" Watch "Extreme Programming" New topic
Author

Extreme Programming

Dale DeMott
Ranch Hand

Joined: Nov 02, 2000
Posts: 515
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!


By failing to prepare, you are preparing to fail.<br />Benjamin Franklin (1706 - 1790)
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Jessica Sant
Sheriff

Joined: Oct 17, 2001
Posts: 4313

... seems oddly like homework....
Dale DeMott
Ranch Hand

Joined: Nov 02, 2000
Posts: 515
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

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Nov 02, 2000
Posts: 515
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

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Feb 26, 2001
Posts: 4446
    
    5

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

Joined: Jul 11, 2001
Posts: 14112
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

Joined: Feb 26, 2001
Posts: 4446
    
    5


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

Joined: Oct 17, 2001
Posts: 4313

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Extreme Programming
 
Similar Threads
Social aspect of eXtreme Programming
To Jared Richardson and Will Gwaltney : Extreme Programming vs Conventional methods
some forum on XP or PP?
Quartet Programming
Pair programming