3 ms·
And quality is in turn at least partly about productivity (i.e., it's usually faster to avoid the bug than to fix it after the fact).
by jtheory 14y ago
And quality is in turn at least partly about productivity (i.e., it's usually faster to avoid the bug than to fix it after the fact).
- seanmcdirmid 14y agoIt really depends if you need the quality or not. Also consider Gabriel's "worse is better." Anyways, doing pair programming can be considered as another tradeoff (as you more than halve the productivity of your team); it shouldn't be valued as always a net positive.
- jtheory 14y agoYup; lots of variables to play with. As long as we're actively aware of the tradeoffs (and adjust approach as needed) it's all good. I don't personally find pair programming very useful most of the time, though I've done it now & then... though I do benefit from the half-way version, which is to occasionally talk through problems I'm working on with other developers (in detail, with code).
- seanmcdirmid 14y agoI personally benefit from the rubber duck approach, but I'm a researcher without so many people to talk to.