Partnership For the Win

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.