With an hour left before the deadline, tensions are high
amongst partners Jim and Matt on Coding Team Alpha. Working separately across
campus, they are communicating via gChat on a bug that neither of them seems to
be able to find. Jim suggests that the FOR loop may be going past the allotted
array indices into segfault territory. A quick change of the parameters, compile,
run, and … Success! No errors. Now for the test cases. Pass, Pass, Pass … Fail.
“What happened?” asks Matt. “The last test case failed” types Jim. “Let me take
a look at it, Go ahead and commit” says Matt. Jim commits the code to their
mutual repository and Matt updates his version. While merging the changes, he
notices the conflict. His code detects the “to” keyword, and has the
regex backend working properly. The repository does not. He compiles and runs
his version. “Mine just passed all the tests” types Matt. “I added the “To”
parser while you were working on that loop.” With all test cases passing the
final version is committed and tagged. With the deadline now achieved, both
members continue on with their nights. Although my partner and I finished days
before the deadline, I can remember situations in the past where I was in this
predicament.
This example shows both benefits and challenges to working
and coding in a group of two people. To go into further detail on the matter, I
will start with the challenges.
Early in this iteration, my commit
messages to subversion were "Less than stellar" as my partner put it.
I would record what changes I did, but would fail to remember exactly
everything I changed in that revision. And I would hope the diffs of
the files would explain what I forgot. The problem though, was not my partner
understanding the changes themselves, but why I changed what I did. He gave me
a format for commit messages. The first line is basically a summary of the
main changes or a title. The preceding lines
are explanations of the why the changes occurred. With this
format I eventually got the hang of committing verbosely and not just trying to
save time.
Our next challenge was
dividing the project. We never formally discussed this. My mentality was just
to work on it as much as I could. And hopefully we would get done early. It
might have been a good idea to assign work to each of us even though the
workload turned out semi-even.
There were many benefits I realized
over the course of the project that I am grateful for, the first being the existence
of subversion. Trying to wrangle email threads or flashdrive swapping or the
always hilarious “emailing the code to yourself” are all methods that should be
left in introductory classes. I wish I had known about subversion much earlier,
I would have set up my own repository for every project I have done since. Next
is the parallel aspect of 2 people. As merge-sort proves, dividing something in
half makes it go faster. I was actually out of town the weekend before the
deadline. I had worked on the project up to that point, and my partner took
over the work for the weekend. When I came back, we joined back up and finished
the project.
