prac8 writeup

(I wasn't present for the prac, so I'll just ramble about a different
experience with pair programming.)

I participated in the ACM programming competition last year and the year
before that. In both cases the structure of the competition was the same: each
team of three members gets access to a single computer to submit answers with.
You could write code on paper, but we all know how inefficient that is, so the
effect is more or less a pair programming effort. 

The problems were mostly solvable through some kind of "Eureka!" moment, like
most math-type programming problems. (There was not just a completeness
requirement to solutions but also a speed one, so brute-force and similar
naive approaches were no good.) This made using paper at least useful for
brainstorming approaches to the problems.

That's the theory, anyway.

We had each team member work on a separate problem on paper, and whoever
thought they had a working solution at any given time typed it up and gave it
a go against some test input. The way it turned out, creating test input and
then trying random solutions that might just work took up the majority of our
problem-solving time. Having only one computer turned out to be a rather
annoying bottleneck.

We didn't each have a machine to hack away at futily, so debugging our
solutions turned into an exercise in pair programming. It was at the very
least getting us further than working on the problems individually. Still,
because of the nature of the problems, the difference was fairly negligible.
We sort of just milled about until someone had a lightbulb go off in their
head and give them the answer.

Slightly different situation, the Cyber Security Challenge that I participated
in this year allowed each of the four members of a team to have their own
computer. These problems were more in line with what I imagine pair
programming is useful for, and the way we ended up doing things was splitting
in to two groups that worked on different problems.

Having four people all work on a single problem seemed like too much
redundancy, but by having a separate pair of eyes to notice idiosyncracies the
other missed turned out to be really useful. A lot of sneaky little oversights
that might have gone unnoticed were picked up as they were typed, instead of
later when it would've caused bugs.

As an example, one problem involved a string format exploit. By injecting a
bunch of %X into the input we were able to get dumps of the program's stack
memory. Analysing this, figuring out what all the bytes meant, and the very
precise but apparently arbitrary numbers we had to use to get the exploit to
work meant a lot of things running around in a single person's head. I often
had my partner note that I'd made some off-by-one error here or there or that
my number was in big-endian when it should be little, saving me the hassle of
trying to figure out the problem on my own. Very effective!

For the most part, my experience with these kinds of pair programming
environments leads me to think that the more complex (not necessarily
difficult) a program is, the more useful pair programming is. When sneaky
little bugs can appear in the code, it's helpful to have someone there not
actively typing to notice them. But when the problem is rather simple (in the
case of the mathy ACM problems) it doesn't really help much, because the
program is small enough for those kinds of bugs not to be such an issue.

Most real programs would fall into the former category, I'd wager.