ISerializable - Roy Osherove's Blog

When people don't want to pair program

Pair programming with 3 programmers? ;)

Why don't we do pair marketing? Or pair management? Or pair engineering? Or pair architecture? Or pair truck driving?

Do you see? It's a silly concept. You either have a team, and you work as a team, or you don't. Why put artificial boundaries on it? Shouldn't you be doing what's right for the project at hand?

Sometimes you need to work with other people. Sometimes, IT IS A HASSLE! That's what everybody who pushes this concept won't admit, but it's true. There simply are times when the others DO get in your way.

But you do it to share knowlege? Harumph I say. If your design sucks and you have no documentation, then you're dead in the water. Where's the mention of stuff like that?

Just like everything else, it's a tool, and it can be abused. Use it where it fits, but not everything is a hammer and not every problem is a nail.

"The code was still much better, but they definitely took more time to do it."

How do you know?

Were they measuring 'productivity' pair-programming and not-pair-programming? How were they measuring code quality?

Maybe they'd think it was necessary if they could see measurable differences.

I still find pair programming quit hard to do with my m8 pulling me out of the zone every other few minutes.

I'm a big advocate of pair programming but only when people are open to it. It's more important to find and encourage a good team dynamic than to enforce a particular methodology. You managed to introduce two very big changes, TDD and pair programming, without a short-term negative impact on the project. That's really impressive. I'd be very proud of the team for sticking with TDD. Even if the team never revisits pair programming you've already had a huge positive impact on how they develop.

Roy: Two opposing (or compatible?) theories on why the programmers you encountered weren't fanatical about pair programming:

1) They're young and immature in their careers. My experience has taught me that most programmers are a pretty arrogant lot immediately after graduating college...and don't like to work closely with anyone (except maybe an older staff programmer for mentoring purposes) because they're too worried about their peers fiinding out their weaknesses (i.e., boundaries of skills and knowledge) and are overly concerned about their "position" and "ladder-climbing" early in their career. (I call this the "They all want to be rock-stars" syndrome...)

2) They're old and mature in their careers. My experence has also taught me that most programmers who have been programming over 15-20 years (like me) are a pretty stubborn lot...and don't like to work closely with their peers (other old programmers), since they're "set in their ways" about the "way to do everything". (I call this the "Don't bother me.....I'm doing IT ALL!" syndrome...)

To summarize the above theory, I believe (and have observed dozens of times...) that the only good pair programmers are those that are equally skilled and knowledgeable and in the middle of their careers (10-15 years). Pairing up a senior programmer with a junior programmer is NOT pair programming...it's mentoring! Pairing up two junior programmers will simply produce a LOT OF CRAP and pairing up two senior programmers will simply produce NOTHING...since they're out in the parking lot beating each other up over their ingrained programming styles! (The way the Chief of Staff and Chief of Medicine on the TV show "Scrubs" are continually at odds with each other comes to mind... I haven't decided which character I idolize more!)

I agree with Joe on most points. Unfortunately, pair programming can simply be the latest fad amongst management to try getting some mythical "productivity improvement" out of programmers (which usually really means trying to meet some insane impossible-to-meet schedule requirement), just like a lot of other hot programming techniques, like XP and TDD and project management technique like off-shoring and out-sourcing. The programming industry has suffered through many of these "fad cycles" whereby management has read some silly overview of the technique in a trade rag and figure they can leverage it to make themselves look good...without understanding the rationale and pitfalls of the technique.

A lot of companies here in Silicon Valley that have adopted XP, TDD, pair programming, etc. have also completely eliminated good up-front design of the application system using good systems analysis and systems design practices.....like writing the dredded specs! I've not encountered a SINGLE programmer out of college in the past 10 years that can either tell me the difference between an EDS (External Deisgn Spec) and IDS (Internal Design Spec) or be able to write ANY kind of spec, given the chance...because colleges by and large have eliminated Systems Analysis and Design courses from their curriculums. (Or they've at least reduced it to a single OPTIONAL course that NO ONE takes...)

These new techniques (XP, TDD, off-shoring, out-sourcing, etc.) are being abused to simply try and provide the MOST software in the LEAST amount of time.....NOT the BEST software in a REASONABLE amount of time. (Remember the hysteria in the industry 5 years ago when the term "web weeks" was coined to denote this "rush the crap out the door" mentaility?) This is one reason hundreds of "dot bomb" companies went out of business when their VC funds dried up: they produced tons of crap (that didn't work)...using the latest "productivity techniques" (like pair programming) to an absurd degree.

Some of them that I toured in downtown Palo Alto 5 years ago were PROUD to have saved a few thousand dollars by NOT supplying each programmer with their own PCs! And the PCs that they were sharing were not only bought 2-3 years used, but were also ridiculously under-powered! (Builds would take hours instead of minutes on a new PC...) It was obvious why those startups failed. (I actually heard at two of those startups the term "web days" used on their schedules instead of "web weeks"...)

Techniques like XP, TDD, off-shorting, out-sourcing, etc. can be made to work, provided they are used for the RIGHT reasons: to get GOOD applications deisgned and coded in a REASONABLE amount of time. Unfortunately, that message has gotten lost at a lot of companies and they only see these techniques as "expense reductions".

Thus, this could be another reason why the programmers you encountered didn't like pair programming: they saw that the use of pair programming was just to try and cut the schedule WAY back...and deliver the code ahead of time...and possibly (heaven forbid!) felt a professional responsibility to NOT PRODUCE CRAP! Was that the case? Inquiring feeble minds want to know!

Steve: wow. thanks for the most interesting comment.
I would say in this case your first statement is true. they are both inexperienced (one a little more experienced than the other ,actually, but not by much, and they both have different strength). the nice thing about seeing them pairing was that everything was done and learnt much more quickly. they were both new to .Net as the project began which pairing gave an opportunity to learn together all the new stuff.
definitely cut back on learning curve time.
and no, your last statement about management time saving could not be further from the truth. this TDD project was done without projecting times based on pair programming or even using TDD. it was projected in the classing waterfall model way.