3 ms·
Does anyone practice part-time pair programming? A day a week, or early on a project, perhaps when laying out the API for some larger system which is then worke
by scrumper 14y ago
Does anyone practice part-time pair programming? A day a week, or early on a project, perhaps when laying out the API for some larger system which is then worked on by individuals?
Curious, as I've never done pair programming. I'm instinctively against it, but with thought I can see it having value in certain parts of the development process.
- gensym 14y agoYes, I practice part-time pair programming, as do a lot of programmers I know. Frankly, I think it's good to pair full-time while you (you, personally or your team) are learning it, but not beyond that. The OP tried pairing for a month - not enough time to learn how to do it well, IMO. People pair for all sorts of reasons - as a continuous code review, knowledge sharing, and mentoring; but as the OP described, it comes at a cost - of flexibility, and of innovative design[1]. It takes experience to learn how the cost/benefit of pairing stacks up for any given situation[2]. One of these days I'll get around to documenting pairing ant-patterns I've witnessed. For now, here's one: Guerrilla Pairing: Programmer A is in the middle of a task. Programmer B is blocked waiting on something so feels the need to pair, notices Programmer A is unpaired, and jumps in. Programmer A will now spend time bringing Programmer B up to speed, at which time, Programmer B becomes unblocked on her original task and jumps back to that, rendering the disruption in Programmer A's day pointless. [1] Any design that cannot be communicated orally or sketched out in code in under 5 minutes is unlikely to emerge from a pair. [2] Situations including type of work, availability of a pair, etc.