blog of Kathy - Pair Programming is NOT always a choice

[Jeff Langr]

Originally posted by Santosh Ram:
With all the Java/J2EE coding practices around I really do not see pair programming as an effective tool in development phase.

Greetings Santosh,

Do you review code after the fact to ensure that it adheres to good practices?

Most shops don't have any formal review process (e.g. Fagan inspections). Even in those that do, the level of coverage is low, and the depth of review is insufficient. And there's rarely a good follow-up process to ensure that standards/practices violations get corrected.

Unfortunately, I've been burned too many times to trust that everyone on the team has the diligence required to keep the software in good shape. I've seen no better way to do it than pairing.

-Jeff-

[Anonymous]

Kathy cites the need for a "gentle introduction is probably all that's needed", and I have to agree. The tragedy of my PP experience was its implementation.

The following "example" is a gross exaggeration, but it demonstrates in brief how PP was introduced into the environment: having read Kent Beck's book, PHB (actually an otherwise very smart man) demands that Joe extend his left arm and Jim extend his right. That done, duct tape is would tight around both extended arms.

Any enthusiasm the coders had for XP/PP (and there was genuine initial enthusiasm) was baked out quickly. The mere sight of one developer seated alone at their desk, even if they were, say, installing Oracle (not a PP activity), was met with, "Guys! Guys! We're supposed to be doing XP here!"

As the summer/project ground on, most other tenets of XP were eventually discarded, and PP became little more than something about which to harp on in reviews. Blech.

I'm definitely not a loner. If allowed to take root and grow, PP is, IMO, a great great thing. Developers naturally talk with, and often pair-code with one another, "Mike, I'm just not seeing this. Can you put another set of eyes on it?" or "This does not jive. I need help" (and sagely colleage points out bad OO)

I look forward to one day again using PP, but have found that it is a hard sell in the past couple shops. The reason is never made explicit, but the vibe is that other developers may have had similar past experiences with it, and now irrationaly growl when "Beck" is uttered.

[Ilja Preuss]

Originally posted by Erick Reid:
I look forward to one day again using PP, but have found that it is a hard sell in the past couple shops. The reason is never made explicit, but the vibe is that other developers may have had similar past experiences with it, and now irrationaly growl when "Beck" is uttered.

I can understand that. But I also don't see any need to utter "Beck" when I in fact can honestly cry for help...

[Anonymous]

But I also don't see any need to utter "Beck" when I in fact can honestly cry for help...

Sorry, Ilja, I don't follow your quip. This is not your fault. I've been studying for an upcoming exam, my sense of humor having been suppressed by hundreds of practice questions. :|

Can you put your feedback another way? I'd really like to get this place test infected, and if you've got ideas on how best to do that, I am all ears.

Aforementioned test is next Monday. I'm looking forward to being done with it, and taking an evening vegging on the couch versus pouring over study guides.

[Ilja Preuss]

Originally posted by Erick Reid:
Can you put your feedback another way?

Sure!

One reason that it's hard to sell Pair Programming, Test Driven Development, you name it, is - well, they aren't interested in getting it.

What they probably are interested in is being more effective, having fun etc. So what if you sold them *that*?

If you need help, ask for someone sitting by you. If someone needs help, volunteer sitting next to them. Don't tell them that you are pair programming, or that Kent Beck says that it's great - *show* them that it's a great, fun, effective way to work.

After some time *then* you can start saying "you know, what we have done the last few months is very much like what Kent Beck calls Pair Programming. He also advises to apply this one technique while PPing - perhaps we should try that, too and see wether it works for us." People are much more likely to listen to you if they can refer it to something they already have experienced.

I highly recommend reading the book "Fearless Change": https://coderanch.com/t/93700/Book-Reviews/Fearless-Change-Patterns-Introducing-New

[Anonymous]

Thanks, Ilja. You are hitting quite close to the topic of my original post in this thread: leading horse to water and shoving his head in shouting, "drink darn you or it'll reflect poorly in your review!" makes for angry, dehydrated horse.

That is sort of like the means used by manager in my past environment to get everyone doing XP/PP. The result was: people got upset and refused an otherwise good idea, and the project suffered.

With one exception, all the developers involved in that forced XP thing eventually left. This is not to say they did so based solely on this failed experiement, but it is one of the straws. Guys grumbled about the "do PP or else" period for a long time after, so it was certainly on their minds.

Your feedback speaks to how I'm trying to go about selling the good stuff in the here and now: by doing it myself and inviting participation. Thanks for reminding me though not to get frustrated and make a mistake similar to those above mentioned manager made.

[Ilja Preuss]

Originally posted by Erick Reid:
leading horse to water and shoving his head in shouting, "drink darn you or it'll reflect poorly in your review!" makes for angry, dehydrated horse.

That is sort of like the means used by manager in my past environment to get everyone doing XP/PP.

Those managers obviously didn't understand what XP is about. It's no coincidence that the very first part of the Agile Manifesto is "individuals and their interactions over processes and tools". XP can only work, in my opinion, when the team *chooses* to do it - not when it is forced to. The latter simply undermines its basic values (which since the second edition of the book also officially includes Respect, by the way).

Thanks for reminding me though not to get frustrated and make a mistake similar to those above mentioned manager made.

Yes, it's important to be reminded of that from time to time, because it often takes a lot of patience. It can take years to get Pair Programming "officially accepted", for example - but it's worth it!

[Anonymous]

Ilja,

Turns out that my local library has a couple copies of "Fearless Change".

[Ilja Preuss]

Originally posted by Erick Reid:
Ilja,

Turns out that my local library has a couple copies of "Fearless Change".

[Don Stadler]

Those managers obviously didn't understand what XP is about. It's no coincidence that the very first part of the Agile Manifesto is "individuals and their interactions over processes and tools". XP can only work, in my opinion, when the team *chooses* to do it - not when it is forced to. The latter simply undermines its basic values (which since the second edition of the book also officially includes Respect, by the way).

This is about as well-stated a point about team dynamics as I've ever seen. A team is not a democracy - but a well-run team contains strong elements of choice. Sometimes there are unattractive parts of a project which need to be done nonetheless - and choice must be tempered with a bit of authority. But in those situations the manager and other team members have to strive to make that work as rewarding as possible. This is one place where Respect figures strongly.

This is not limited to xP, BTW - it's pretty much a universal truth in my experience.

[Ilja Preuss]

Originally posted by Don Stadler:
A team is not a democracy - but a well-run team contains strong elements of choice.

Actually I think a team can be much stronger than a democracy. In a democracy, the minority often has to live with what the majority wants. A well working team most often works to get mutual understanding and tries to find a solution *everyone* agrees to is the best solution at hand. (I highly recommend the book "A Facilitator's Guide to Participatory Decision Making" on this topic.)

[shailesh sonavadekar]

Originally posted by Linda Rising:
We used to believe that PP took twice as long as working alone. It makes sense. Now there is data from experiments to show that this is not the case. It's true that there can be a learning curve for some pairs, but the interesting result is that there isn't much of an effort penalty and sometimes there is no penalty. What the data shows is that the quality of the solution is greater than it would be for either partner coding alone. Laurie Williams has an excellent book on the subject with lots of data and intriguing stories -- see Pair Programming Illuminated.

hi there , linda. it is really really great seeing you after a long long time on ranch after your pattern almanac book. seems that busy writing new one. all the best.

you are right. there will be learning curve. it is something like who is sitting for coding sees the trees & the person who is seating as other partner is pair behind coder sees forest. sonia, just try it. i feel that you will realize the benefit. some times 1+1 = 11 right ??? if the partner is lateral thinker like de bono ???


with warm regards
Shailesh
[ July 13, 2005: Message edited by: shailesh sonavadekar ]

[Bing Shiao]

Originally posted by shailesh sonavadekar:

some times 1+1 = 11 right ??? if the partner is lateral thinker like de bono ???

This remind me a pice of code I've seen few days ago.

SELECT CASE_TITLE, CASE_NUM FROM CASE WHERE CASE_ID = ? AND [B](1 = 1)[/B]  

Why (1 = 1) is there?

I'm just wondering if this developer was mad about something and was trying to express in his code?

Pair programming would have caught this mistake.
[ July 16, 2005: Message edited by: Chern-Jer Shiao ]

[Lasse Koskela]

Originally posted by Chern-Jer Shiao:

SELECT CASE_TITLE, CASE_NUM FROM CASE WHERE CASE_ID = ? AND [B](1 = 1)[/B]

Why (1 = 1) is there?

I'm just wondering if this developer was mad about something and was trying to express in his code?

Pair programming would have caught this mistake.

That might not be a mistake but a feature... I remember we once had to add a "AND (1 = 1)" into an SQL template simply because the framework we were using didn't handle some awkward situation unless we had that seemingly useless constraint in place...

[Ilja Preuss]

Originally posted by Lasse Koskela:

That might not be a mistake but a feature... I remember we once had to add a "AND (1 = 1)" into an SQL template simply because the framework we were using didn't handle some awkward situation unless we had that seemingly useless constraint in place...

Oh, yes, the joys of using frameworks...

In those cases, I find it to be vitally important to have a test case in place that fails if someone should (with good intentions) remove the "unecessary" code...

[ram kol]

never heard of PP. But in data cleanse project, did PP with other team member. PP is always I believe, a way of XP. If it is RUP, then PP is good for just maintaining the standards.

any comments....