Software mistakes can be pretty dire and if you want to ensure quality, in practice, you will want different eyes to look at the code. Which also lends redundancy, if someone wishes to move on.
The easiest time to catch mistakes is early.
The easiest time to catch mistakes is early.
Absolutely, but again, they don't happen as you're coding, unlike aviation or surgery.
> if you want to ensure quality, in practice, you will want different eyes to look at the code
Totally agree, but that's an argument for code review, not pair programming. PP is a way to do code review, but I'd argue it's not a very good way, since you're asking the authors to review the code.
> The easiest time to catch mistakes is early. TDD and CI are a more effective way of doing this.
When do they occur?
> PP is a way to do code review, but I'd argue it's not a very good way, since you're asking the authors to review the code.
I'd argue that it is a good way, based on my experience of both methods. Code reviews are better than winging it, but given the choice between a PR-and-review process and pair programming with trunk development, I'd take the latter every time.
I agree with the virtues of TDD and CI, I see pair programming as a useful way to help with TDD.
> I'd argue that it is a good way, based on my experience of both methods.
And with similar experience, I’d disagree. Paired programmers are focused on writing the code not reviewing. The whole point of code reviews is to let someone divorced from the problem solving process objectively the code.
The easiest time to catch a mistake is when it's made, which is as true of surgery or flight as of software development.
That's why I rely on type systems, tests and whenever I can, someone next to me asking "why?".
pair programming and the articles proposing it do nothing to help catch mistakes early. i would argue that they even delay catching mistakes due to what i'd call deconstructive interference during the implementation process.
there are plenty of much more systematic ways to catch mistakes earlier than just slapping pair programming onto the software process.