On 8/30/2011 7:32 AM, Bryce Martin wrote:
You're missing the point of pair programming. Its about tackling a
problem with 2 heads, cutting the thinking time down, and getting a
product iteration out. We can make claims about super programmers not
benefitting and yada yada yada... but if a super programmer is working on
a sufficiently hard problem then pairing with another super programmer
would make that problem much easier to tackle. This works especially well
when needing to melt two areas of expertise. Its not about syntax and
style... that is what the language and style guides are for. Its about
solving a problem with as few bumps in the road as possible. Two sets of
eyes means automatic double checking of the code, auto code review as
someone else had said.
I get all that, Bryce. It just doesn't see effective to me. Well, yes
and no. You actually make two separate arguments: two heads for design,
and two heads for coding. The two heads for design I understand but
frankly I have always had joint design sessions where we discuss the
architectural issues and the design points. They are unstructured and
loud and a lot of fun (and occasionally a bit of heat as well). And
then eventually we come to consensus and we move on to programming.
For programming though I just don't get the concept. One person sitting
while another types code? If you make enough errors that another
full-time person watching you code is cost-effective, then I submit that
perhaps programming isn't your calling. Think about this realistically
- while you are programming in a day, how many unforced errors do you
make that someone can catch just by watching you type? Is it worth
another full-time programmer as good as you to sit and catch those? In
other words, do you make so many typos in a day that it takes you a
whole additional day to fix them?
On the other hand, if you're doing design decisions during programming,
then your design sessions weren't effective. I mean, how many design
problems do you need to solve during your programming that you need help?
Maybe I don't get it. It seems to me that a lot of these "agile"
techniques are about designing on the fly, and refactoring, and meeting
changing requirements, and that upfront design is impossible, and that
you can only develop applications effectively in a reactionary mode.
Sort of like "we have to pass the bill to see what's in it". I don't
buy that. Maybe it works in games or something, I don't know. But to
me top-down design is still a fundamental requirement for business
development.
But hey, that's me. I'm old. I like RPG. What can I say?
Joe
midrange.com
