DueDates Project Review

Premise: In this posting, I’ll continue from last week’s first iteration of our class project called DueDates. This week I was tasked to evaluate three DueDates project groups and also receive seven reviews of my implementation of the same project. Again I’ll be using Google’s Project Hosting site as my primary source code versioning and issue tracking system tool.
Setup for Review: So how do I put out a package to the world for developers to critique and annotate my work without interfering with my main code-line? Well, SVN provides a concept of creating snapshots of your production line code, called “tags”. Tags are meant for production version-labeled releases of a project. It provides a workable copy of the file-system at a certain point in time of your project. This can be easily done by the commands below. *Note that this would be exactly what a reviewer needs to do prior to evaluating your work. *Also to get the BASE_URL, you may try using the command: svn info - displays the details of the current svn repo. Or svn info | grep URL for just the base url.

svn copy BASE_URL/trunk BASE_URL/tags/review_release
-m “Tagging a review release of main line”

My Review Process: Google’s Project Hosting review tools provide developers the essentials to annotate and evaluate project source code in an effective and efficient manner. It gives reviewer’s, who must first be members of the project, the ability to leave comments within the actual project source file. When the source file is finalized and the reviewer is satisfied by their comments, then they can easily publish those results to the project. After the comments are published, the owners of the project are notified by email(s) of those comments. This definitely made my job as a reviewer better, since I’ll be able to optimize my time to focus on reviewing the project code, and it gives the owners of the project immediate feedback.
Reflecting on Results: During this review process I’ve gained insight into how to improve my code as well as learn the mistakes that I’ve made throughout the course of my implementation. In many ways, I could say “I approached it all wrong,” but by the indication of some feedback, I was also doing something right. Documentation was the main thing I knew that would have to be sacrificed due to our time constraints. Therefore, people were totally oblivious as to what my project expected as an input and output. The project was a total black box, in the front, middle and back. Since I did not pay close attention to my audience, it was difficult for people (both users and developers) to use or expand my system. However, I’m glad to say that there were some people who reached out to support. It was evidently helpful and gratifying to us both. During this process, I also found a way to “switch” between production lines. The reason for this was that I needed to repair the broken tag distribution for review. Before doing this, I sent out a mass email detailing the reasons. Here are the commands to switch between the trunk and tags (it also goes the same for any directory layout that you build through SVN):

svn switch BASE_URL/tags/review_release

Pretty nifty, huh? Indeed, I thought so too. After I got done making changes to the review_release version, I quickly switched back to the trunk's main code line to continue coding on the trunk. I was surprised to notice one reviewer who really felt inspired by my implementation of an error logger (ErrorLogger.java). My first intent for this class was to just parse out the command line arguments, but it became something more along the lines of a stack dump error logging tool. It currently parses out the arguments, separates them by [args] => [options - prefixed with a hyphen] [parameters - non-hyphen parameters (actual values)]. Options are pre-populated with somewhat of a unix/linux inspired command, "-v" or "-verbose". The final feature was the ol' error handling messages (friendly or verbose) depending on the passed options. Overall there were lots of small details that needed to be worked out of the beta stages of this increment. My goal from this point on is to sculpt out the essentials of the application, make it more abstract or general, and extended upon new ideas.

A lesson learned: I wanted to express this on my last posting but it was difficult to express matters under certain time constraints. I’ll start off by mentioning about what went wrong in my group’s implementation and then how we are currently going about to improving ourselves for future increments. I would like to tag this project during this point in time, called “death by email”. My group partner and I only had one official meet outside of class during the first week of working on this project. In my opinion it was horrifying to communicate with someone for the first time and barely knowing them. We both made the mistake by not getting to know each other better outside of class. Due to this slight alienation, we caused each other to have flawed predictions of one another. These preconceptions proved to be inaccurate and misleading. It was very difficult to see whether or not a team member was having a hard time with the project or if they were suffering from other external issues. During the course of this project, I learned that you are only as strong as your weakest link. Apparently we both had strengths and weaknesses. If we had communicated better straight from the get-go, and came together to pick at our flaws, then the project would have turned out better as a whole. My project group member and I have been taking the time out of our busy schedules to do regular fact-to-face meetings that last at least 30 minutes long. We’ve started to put this into practice rather than having to deal with just emailing each other progress reports. Hopefully we’ll be better off in our next increment, this coming week.