Comments on Jay Fields' Thoughts: Life After Pair Programming

Really good honest post. For me, crucial is not fo...

2012-01-28T08:23:13.408-05:00

Really good honest post. For me, crucial is not forcing any such practise on anyone (I know organisations where this does happen). I'm also firmly of the opinion that it's not just coders should consider pairing:

http://bit.ly/beyond-pairing

I also consider that breaking routines by pairing great has potential to stimulate curiosity - it's all too easy to get stuck in ruts.

I'm surprised that you don't pair any long...

2011-10-12T19:24:28.867-04:00

I'm surprised that you don't pair any longer. Your pitch to management about how you equate the benefits of pairing to being 2X the manpower for the same bang sounds like you're not mindful of all the benefits of pair programing. But I'm not going to try to convert you. You've already made up your mind.

It's interesting to hear about someone who has expressed that they don't pair program any longer.

Interesting article. I've paired in a few sit...

2011-09-02T11:28:57.747-04:00

Interesting article. I've paired in a few situations when it was very beneficial to me, to my partner and to our employer: 1) When I was a "trainee" 2) When I worked alongside the primary developer of a new, complex, shared code library 3) When working on a new app using tech that was new to both of us. But pair programming is not right for everyone nor for every situation. Sometimes a simple code review is all it takes to transfer knowledge, especially with mature apps and developers who are already fluent in them.

Well done! I find your analysis persuasive with re...

2011-09-01T21:03:25.680-04:00

Well done! I find your analysis persuasive with respect to the alleged pairing benefits you identified.

But I think pair programming has one more benefit that you (and the referenced article) neglected to mention: a pair can catch and reduce the ever-present danger of WTF development.

"WTF" is my most frequent reaction to the code I read ... whether written by me or others. My code is glorious when I write it; a few days later, however, and I'm wondering who wrote this crap.

Does that sound familiar? I'll just speak for myself. When programming alone, all too often I pursue hair-brained ideas, corner cases, and features that I'm sure I'm going to need some day.

I've spent hours polishing a piece of code that does things it shouldn't in ways it shouldn't with an API that no one will understand.

Another voice might have caught my wandering muse and pulled me back on better course ... if only by obliging me to explain what-the-heck I am doing.

I've never met the programmer who is immune to this disease.

Of course a pair can produce delusional code too; they are just less likely to do so.

Does this benefit alone justify pairing? It might if anyone could demonstrate that the time/pain saved by avoiding lone-wolf stupidities compensated for the cost of two programmers working on the same code.

I don't know if such a study exists or how you would even design such a study. My gut tells me that the benefit would be measurable but not sufficient to justify the cost ... at least not in most projects. I remain open to a rebuttal on this score.

I should add that code reviews are supposed to catch WTF moments without the double headcount cost of pairing. I don't know; in all my years I've never seen or been in an environment with adequate code reviews.

In sum, I'm pretty sure I agree with you that pairing usually doesn't pay ... but it has more to offer than you grant it ... at least in reining in WTF.

Cheers!

I should add an addendum: recognizing that there a...

2011-09-01T10:23:13.695-04:00

I should add an addendum: recognizing that there are better ways to 'pair' than others does not invalidate Jay's point - there are still places where pairing is not the best use of time... but more often than not, I find people use posts like Jay's to just avoid collaboration all together... basically, it sounds like Jay and his boss are getting all the benefits of pairing through their other communications - more like they are in a constant state of pairing - because they are in synch. It does make me wonder, however, what would happen if they added additional perspectives to their team through a third or fourth member.

Interesting. I agree that there are certainly plac...

2011-09-01T10:05:40.323-04:00

Interesting. I agree that there are certainly places where pairing may not provide a balanced benefit and a small two person team is SOMETIMES one of those places. At the same time, as I engage with more areas of business, I find pairing more and more helpful in some of those two person relationships... such as pairing with different managers, BA's, PM's. Pairing in this context is not just a error check - it is a way to infuse different views/experiences into the creative process. It can also be a way that a manager can gain insight into the day-to-day realities of those he manages. Also, all pairing is not equal... I love this video showing the differences between just sitting together and "pairing" - http://agile.dzone.com/videos/pair-programming-show?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+zones%2Fagile+(Agile+Zone)

It's good to apply agile methods in an agile w...

2011-09-01T02:19:58.605-04:00

It's good to apply agile methods in an agile way, as opposed to the near religious fanaticism that many apply them.

My pair was a reasonably good looking woman. I end...

2011-09-01T01:33:41.579-04:00

My pair was a reasonably good looking woman. I ended up having sex with her and I had to do large chunk of her work too

Worderful point of view, just figured you wrote my...

2011-08-31T22:58:26.484-04:00

Worderful point of view, just figured you wrote my feelings :)

Congrats.

When Sergey Brin wrote "google", who was...

2011-08-31T22:05:25.977-04:00

When Sergey Brin wrote "google", who was pairing with him? How is "google" quality?

What if there is nobody to pair with :-(

2011-08-31T20:30:05.948-04:00

What if there is nobody to pair with :-(

A good post. Programmers have always worked togeth...

2011-08-31T17:56:20.135-04:00

A good post. Programmers have always worked together when useful. But pairing is only useful where a high degree of knowledge transfer occurs, or at the point in the skill/difficulty graph where a second brain helps catch and correct serious design flaws (e.g. a trainee can learn from a senior, or two seniors can thrash out a critical design). However, when you have mature/capable programmers working on typical day to day designs (the simpler stuff rather than major architectural decisions) there is often very little to gain from expending two programmers on the task - if they can both provide an adequate (or better) solution, it is often pointless or downright wasteful to pair them. My view is always to use the right tool for the job, and pairing is yet another tool that should be applied in moderation.

Nice blurb. It reminds me of many situations wher...

2011-08-31T13:14:26.971-04:00

Nice blurb.

It reminds me of many situations where CTO's insist on patterns.
"What pattern are you going to follow in implementing this widget ?"

Reply: "It's a frickin widget !!! All widgets use the anti-pattern. (unless of coarse afterwards you find a pattern in it ;-))"

As with all things, they must be taken in context.

Jay, you've written an excellent, thought prov...

2011-08-31T11:48:39.717-04:00

Jay, you've written an excellent, thought provoking article on the whole. I am a little concerned that in pursuit of your point, you're pulling out numbers like "twice as many man-hours for a 10% better solution," without providing your basis for those specifics. In my experience of pairing and of not pairing, I have never been able to arrive at numbers which are that precise or cut-and-dried.

On the whole, however, I do think you have an intriguing thesis; that pairing is less important where the work domain and codebase are more stable, and where the programmers have parity in competence. This means, presumably, that *turbulence in communication with the stakeholders is minimal, and *turbulence in communication between team members (due partly to variance in skill levels) is also minimal. This factor is further emphasized by the notion of a small team (which you mentioned).

* by "turbulence" I do not mean conflict, but merely mis-matched expectations or conceptualizations.

I prefer pair programming because I prefer work where turbulence has not yet been normalized: newer initiatives where neither the business folks nor the programmers already know most of what they need to know in order to accomplish what they need to accomplish. For me to avoid pair programming in a context like that would amount to living in denial, the metaphorical equivalent to searching under the lamp post because the light is better there. Pair programming is hard work precisely because it is built for doing hard things.

The maintenance of stable systems exerts less demand in terms of communication/collaboration and also in terms of ideation in a new domain. But when an organization needs (or desires) to pivot in some way, we can't take for granted that lightweight, ad-hoc collaboration will get the job done.

(For the record, I'm not saying that a maintenance cycle in the life of an organization is a bad thing. I believe organizations, just like people, need rest cycles. Pivoting may be dynamic and even dramatic, but perpetual pivoting is madness.)

A balanced viewpoint is important. There is not on...

2011-08-31T11:12:14.919-04:00

A balanced viewpoint is important. There is not only one way to do things. My team is also very small (3 developers counting my manager). I find that we switch back and forth between pair programming and not since we have a young developer on the team. However, I can't stand those who are so dogmatic and can't be flexible. It's another way of being "Agile".

This depends on the programmers for the most part....

2011-08-31T10:29:14.001-04:00

This depends on the programmers for the most part. If they are compatible to be a team, they can probably get good results.

It’s a waste of time unless you are mentoring some...

2011-08-31T10:23:19.004-04:00

It’s a waste of time unless you are mentoring someone else(an entry level guy)… or perhaps to fulfill the lack of interpersonal relationships :)

excellent article

I just wanted to say that pair programming is WTF?...

2011-08-31T09:57:42.607-04:00

I just wanted to say that pair programming is WTF???? Guess you buy people for pair programming to pay each half of the salary. Why oh why would I want someone to be around my neck whole day? Highly unproductive!!!!

I feel tempted to conclude from articles like thes...

2011-08-31T09:00:40.671-04:00

I feel tempted to conclude from articles like these that pair programming acts like finger exercises for piano and organ players. Some lunatic fringe continue to enjoy the exercises, but most people simply play them in order to build up their general dexterity and evenness. Then we move on to studies, we play then regularly, but we rarely, if ever, perform them, unless they come from Czerny or Chopin, because those ones sound like music.

I hated finger exercises, but I do prefer pairing. Perhaps I just like collaboration, and pair programming represents the most common way I get to do that. I imagine that if I worked on another Java project -- a platform I once knew very well -- that after I paired long enough to get up to speed on the latest and greatest tricks and tools, and assuming that I worked exclusively with people at a similar level of knowledge and experience... I might not insist on pairing so much. I might instead insist on pairing with business people.

I hadn't thought about that before, so thanks, Jay, for prompting me to think about it.

@Dave "The 'motivated teammates' aspe...

2011-08-31T08:39:25.653-04:00

@Dave "The 'motivated teammates' aspect threw me. In your experience, have you found that pairing works well with unmotivated teammates?"

Unmotivated teammates can't hide when pairing is occurring. They either join in and get work done, or it becomes obvious that they need to be replaced - in my experience.

"The 'talented and well-seasoned teammates (similar skill level, and skilled overall)' aspect is important, and in my experience, that's a rare team."

It doesn't feel rare to me, as I feel like I could get that at forward.co.uk, thinkrelevance.com, or drw.com - but in the grand scheme of things I guess those places are 'rare'. I optimize for working on those types of teams as solving domain problems are the ones that are the most attractive to me - but that's just my approach, not a prescription for others.

I tend to think that people who say that you shoul...

2011-08-31T07:45:45.697-04:00

I tend to think that people who say that you should do something 100% of the time are always wrong. I'm a huge TDD fan but I don't do it 100% of the time and I don't have 100% test coverage. It always depends on the situation.

There are pendulum swings in software development, and the pendulum is swinging from the get-it-done-fast-no-testing mantra to an emphasis on quality, which is good, but it makes me wonder if now we emphasize quality too much and speed not enough (I know that sounds heretical, but think about it). Like you said, is it worth it to spend 2x the time for an extra 10% benefit?

But that being said, pair programming is definitely good, but I think you have to do the right thing in each situation.

Jay, "Delete is still my favorite refactorin...

2011-08-31T07:43:30.404-04:00

Jay,

"Delete is still my favorite refactoring and I do it as often as possible on my quests for superior solutions." This was my favorite part. Great quote.

The "motivated teammates" aspect threw me. In your experience, have you found that pairing works well with unmotivated teammates?

The "talented and well-seasoned teammates (similar skill level, and skilled overall)" aspect is important, and in my experience, that's a rare team. But maybe that's because I enjoy working with apprentices. :)

@Jack That said, I don't remember the last pro...

2011-08-31T07:37:23.699-04:00

@Jack That said, I don't remember the last programmer I met who couldn't benefit a lot from practising TDD. I have met programmers who simply can't pair -- as in, it's bad for their health to pair -- although I can count them on one hand.

@JB Totally. A practice in and of itself is just t...

2011-08-31T02:35:32.257-04:00

@JB Totally. A practice in and of itself is just that--it's when we all get in the way and throw absolutes around that things get messy IMHO.

I don't come across many methodologies or concepts that have no value, all the time. They're just not valuable enough to be spread. I do come across some excellent ideas and techniques that get somehow turned into a panacea. Listening, as you said, and trying things out on your own, are key...and really not that hard to do after all.

Over the years I've described pairing to other...

2011-08-30T20:51:14.185-04:00

Over the years I've described pairing to other devs this way: you probably already "pair" 5-10% of the time with your coworkers - you occasionally sit with someone else and solve a problem. "Pairing" is like that except you do it most of the time.

Lately I've been wondering if all that time the balance was much more "correct" pre-XP.

I agree with everything in this article, including where pairing is still valuable. It's all very well said.

(a former Pivot / current Squivot)