Xp Without Pair Programming

Some people find PairProgramming unbearable for various reasons: It slows me down; it's faster for me to code it than communicate it; etc. (More examples below.) They might choose to do XP without PairProgramming. BookXp, and many proponents of XP would argue that speeding you up can often slow the project down. Basically, avoiding PairProgramming because of its negative side effects also avoids its positive side effects, many of which are targeted at the team level, not necessarily the individual level.

See also: ExtremeProgrammingForOne

I personally find a lot of value in a lot of what comes under the XP banner. However, I still can't bring myself to embrace PairProgramming.

Why ?

I think with me it's primarily a QualityOfWorkExperience? issue. I will grant that, when pairing minds that "mesh"/"meld" to a large enough extent, a PairOfProgrammers? could quite possibly get more done (and better done) than a SoloProgrammer?. However, it comes down to aesthetics, in large part. Enjoyment. I enjoy programming alone. I like to think that my enjoyment of the process (and the lack of person-to-person communication overhead) gives me an edge over most advantages enjoyed by the IdealizedProgrammerPair?.

Tell us of the first few times you tried it.

I have been forced to do it a number of times, just in the normal course of a general software project. It just seems to me that, pairings, in the real world, always fall far short of the ideal. It has always been much more efficient and productive for me to program on my own, than to "tag team" with another.

Forced to PairProgram? ...by someone who needed your help to figure out that bit of code you'd written last night at 2am -- DavidAndersen?

It's almost always faster for me to program things directly once I have the idea in my head because I find it incredibly difficult to convey what I'm thinking to others. Occasionally I'm completely lost in the weeds and I need someone to hit me, so it's not always true that it's best to let me just type. However, it's always the case that whenever I code something by myself I've made myself a bottleneck for that part of the system as I'm the only person willing to change the code I've written. When PairProgramming, the opportunity for someone else to work on the system arises. With a culture of continuous PairProgramming, with constantly switching pairs, everyone should feel confident to modify the system. This makes the team move faster, even if I individually do not. Of course, if others weren't so chicken, maybe this wouldn't be a problem. I modify code written by others all the time. I believe in CollectiveCodeOwnership. I never say "my code" unless I actually own the copyright. -- SunirShah

See: ToAyoungExtremist

I object! I don't think in objects. I think in code. The fastest way for me to communicate an idea is to code it. I've been programming since I was four. You try teaching English grammar to someone who isn't a native speaker. They'll probably have a better chance teaching you because they had to formally learn the grammar whereas you internalized it. That isn't an excuse. I work hard to improve my communication skills, but it's still usually faster to code something than to speak it, often because most programmers (and "architects") haven't realized the fundamental concepts in computer science. -- SunirShah

I'm not sure what you're objecting to. The "young extremist" of Kent's parable seems to be saying the same thing you say above : "The idea is in my head, but I can't seem to communicate it effectively - other than coding it myself". I can't see that it makes much of a difference whether you "think in objects" or "think in code" - Kent's point would remain the same : as long as it's in your head, it's an abstraction, a vision. What Kent seems to be saying is : when you have pared down the vision to something you can just explain to other people (without the explanation taking forever), you'll know for sure it's simple enough to be worth using. -- LaurentBossavit

: "Visions of objects screw this entire process into the ground. When you already see the illusion of objects, you stop seeing everything that could tell you that you were wrong. The cases where our visions came true only exacerbate the problem, as we make the vision the goal, not the system. "

I took that to mean seeing abstract bubbles and arrows in your head. I probably misunderstood the page. Either way, my point is that even though I can eventually communicate what I think in English, often this is not faster than coding it and then showing it to others. This is how PairProgramming normally works anyway. "Gimme the keyboard. I've got an idea." -- SunirShah

Or I misunderstood; it's hard to tell, what with the Zen reference and all. But "gimme the keyboard" sounds like most of what is needed, English-wise, to pair effectively. The point (or so it seems to me) is that we want the code to come from a solid team consensus of what should be done (or "what the code wants to be"), rather than from a single "vision"; and that a good way for this consensus to form is within pairs, then spreading as pairs switch. -- lb

Years later... it seems like I was addressing those that think they code faster by themselves. The "for instance" was myself: I think I program faster by myself, but I prefer not to because it's worse for everybody. Coding faster is not the same as developing faster, by the way. It just means typing faster. -- SunirShah

Some of you people sound like your still letting your ego do the talking.

I think you can get 90% of the benefits of PairProgramming without most of it's negatives. PairProgramming gives you ongoing design review, code review, better adherence to standards, avoidance of going on tangents, and better design due to more brain-power. (Some of this can be handled using tools that statically review/check your code for issues, like CheckStyle, PeeEmDee (PMD), JDepend, Simian.) We only pair 1-2 hours per day; 1-3 times per day for 30-90min each. During this time we review code written since last session and micro-design the next batch of tasks. Email is used for minor questions and status updates. The pair reconvenes whenever the micro-design if fully coded. Spikes, acceptance tests, and tricky code are the only times programming as a pair is needed. I suggest PairProgramming be replaced with the term PairDesigning. -- MikeSlattery

Mike, I really like your idea of PairDesigning. I am currently working on a smallish project. We are 2 people in Australia and 3 in France. The 2 of us in Oz work just like you suggested. We make small design decisions together, and then work separately on 2 separate parts of the project. We also debug small problems together, but, when things are going well we enjoy working separately. In the evening, we talk with our team in France about how we each advanced during the day (time difference is a real problem) and about what problems we are having. NissimHadar

CategoryPairProgramming ExtremeProgrammingForOne