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. 


  1. Andrew,

    I like your comparison of divide and conquer of merge sort to how it is applied to our programming project. This is certainly true, imagine that how many numbers you can sort manually without use any pen and papers. But we can always divide the input set to be below our limit. This is to say no matter how big a project can be, we can always use such technique to utilize.

    Regarding to you experience of iteration 1, I would suggest to come up with requirements and design before attempting to implement. Remember that, we are using iterative model, that each iteration we need to design / test. Build and fix model as suggested in Berry's paper may not be the best model we should use.


    Buyu Chen.

  2. Ahh, unknown errors... a partner will always be useful to catch these. especially if subversion points them out. i may not be the greatest fan of subversion, but i do see how it can be useful. I really liked how your short story highlighted that in the beginning.
    -Jakub Nemec

  3. Well, I thank you (or your partner, rather), for the format for subversion commit messages. Mine have also been "less than stellar", but I wasn't quite sure on a better way to do them.
    I also enjoyed your little mini-story at the beginning. It was a pretty quality attention-grabber. Keep up the good writing!

  4. I liked the story in the beginning because who among us hasn't been there before, but your story shows how subversion can definitely help. I also like the idea of having a format for your commit messages. It would probably help avoid confusion for me and my partner as well.

    Jon Anderson