3 ms·
The goal in sole programming is also to produce code. The value-add of pair programming is usually knowledge transfer, rather than code produced. And it's not j
by barrkel 5y ago
The goal in sole programming is also to produce code. The value-add of pair programming is usually knowledge transfer, rather than code produced. And it's not just knowledge about the code being written, but work practices too.
- twic 5y agoThe goal of pair-programming in XP is to produce better code, faster. The idea that pair programming is mainly a teaching / learning mechanism is very widespread, but it's a profound misunderstanding.
- barrkel 5y agoI don't honestly care tuppence for XP. It was an interesting revolutionary position in the mid 2000s, but an historical artifact now. I've never used pairing, nor seen it used, other than as a way of helping get someone up to speed on a task in an area or process unfamiliar to them.
- regularfry 5y agoNot the way it's been sold to me. The goal is precisely to produce code, more effectively than two devs would individually, because a concurrent second pair of eyes avoids blind alleys and problems that would otherwise take a handoff to spot, and handoffs are efficiency tarpits. Knowledge transfer is an unavoidable beneficial side-effect, but it's not the point.
- CRConrad 5y agoFWIW, although I only ever got to do very little pair programming (and it's long ago now), from all I heard about it (and the way it worked for us when we used it), I've got the same impression as regularfry and twic: It's at least as much about the actual code produced as any knowledge transfer. Seems to me that it has suffered the same fate as so many other original "Agile" practices: The image of them nowadays is gravely distorted, sometimes to the extent of being a caricature, of what they originally meant.