March 2012 Archives

Iteration 1 Reflection

| No Comments

In the process of implementing iteration one of our project, my partner and I experimented with a couple ways of organizing our work. The first third of the iteration, we worked cooperatively, analyzing code on the same screen. We discussed the steps that we needed to take in order to reach our initial goal of basic functionality. Once we found a solution and developed a good concept of the functionality, we began coding up the test cases. We decided, since we were squeezed for time, that we would only test the basic functionality and the edge cases. At first we were planning to split up by having a person write the test cases, and the second writing the actual function. Although this would be efficient, we decided it would be best to write our code revolving around the test-cases instead of winging each part individually, and fixing it later. Thus we both completed work on the test cases first, and then finished the functionality afterwards. Once we have created our test cases we started working on the initial functionality. By the end of this day, we had finished the functionality, and passed all test cases. One problem that was discovered along this process was that we were asserting incorrect values in the test cases. Since we modeled our test cases to also read expressions using matchRegex and makeRegex, instead of just specifying a value, that lead to difficulties in actual correctness. Thus although the test cases passed, the functionality was incorrect. We then decided to write new test cases to accomplish functionality, in doing so we discovered that there was error in our expressions. This made sense because if we use an incorrect expression as a test case, and test it with the same incorrect expression, then clearly this it will show as correct but is obviously incorrect. Thus by implementing these new test cases in which just tests the actual value of the string expected, the correctness of the function is expressed concisely. After we were finished with the first third we decided to be done for the day and work on it the next. Since I commute to class and I didn't have class the next day, I stayed home and we decided that we would work and communicate through Skype and SSH. This was an experiment since neither my partner nor I have done this type of synchronous work before.

When we met the next day (through Skype) we discussed on how to proceed on the next stage. Since the day before we only expressed basic functionality, specifically one function matching expression, we decided to expand upon that and create the matching expressions for the rest of the tokens. Thus we literally divided the work of creating test cases into two pieces. I would work on the first half of the tokens, and my partner would work on the second half of it using the initial functional test case as our schema. When we were finished with that he first committed the revisions to the server. I then updated and SVN gave me the message that the merge was a success. However, when I compiled these new test cases, it was giving me a syntax error and I was confused as to why this was happening. Before my partner and I merged codes, we both ran the compiler on the new test cases to assure that it went through. Thus a good option to consider is that the merge, although said it was successful, merged the files incorrectly. I then analyzed the merge and saw that the SVN merge, inputted a whole function within the bounds of another function leading to an error. This was an easy fix with a cut and paste. Once these fully compiled, I recommitted with the merge and my partner updated to the new revision. The next step was creating the scanner. Before starting the code we first discussed on how tokens are identified. For example, if we encounter a keyword inside a variable, how should we handle it? Another would be a number followed by a variable with no spaces. At first I thought this would be a lexical error but after discussing further, we figured that it would then be handled by the parser. If there were a space in between the number and the variable, it would not be of the correct grammar to do such a thing. When we figured how different texts should be classified, we began coding up our scanner. Again, we split up our work so that my partner would do the first half, and I would do the second. Once this was done we committed and merged; similar to our test cases. This time after merging, we were compelled to check the correctness of the merge before compiling. This time, it happened to merge correctly thus we ran the compiler. As expected, the compiler exploded in errors in which we needed to fix our code, particularly each expression and possibly a re-ordering of comparisons. Cringing at the errors, I recommitted the merged code so that my partner could also see them.

Since the above comparisons could influence the correctness of comparisons that are below in the scanner, we decided to analyze and fix each comparison together, thus focusing on parts that are actually needed. After attempting to fix each comparison, we would see if the corresponding test case would pass. If it would, we would move down the list, otherwise we would try to fix the expression. In analyzing some of the test-cases, we saw that incorrect comparisons below would also lead to the incorrectness of the test-cases from above. Thus we would have to fix those comparisons first before moving back to the current test-case. One huge error in our expression was that the string literal token would take the very first quote in our text, matching it with the very last quote in our text. Thus there would be one string literal with 90% of the code inside of it, which is obviously incorrect. After hours of fixing all the errors, all the test cases passed. Following that, we committed to the repository. One error we encountered earlier was that I would update to the new revision that my partner has just committed, and although updating the files we are currently editing, there was still an inconsistency in our base code, even though we have both added all files in the folder to the repository. So to assure that we committed the correct version my partner deleted his old source folder and reupdated to get the full-new repository version. He then reran the compiled code with all test-cases passing.

The way in which my partner and I carried out the process of this iteration I would say went relatively smooth. Since before carrying out each action, we would discuss the reasons in why we are doing it, it was fairly controlled. A situation that did not work out so well was when we were working on the project over SSH and Skype, specifically the point where we were trying to fix errors. I would try to bounce ideas off my partner suggesting possible errors, although he was giving feedback, I had a feeling that he wasn't attempting to analyze the code in depth. If we were working together, I would easily be able to see that he is analyzing the code by a quick glimpse at his workspace. I think a fairly obvious solution to this problem would be to define the lines in which to split up the large problem into two separate parts to be worked on by us individually. Thus each person feels responsible for separate segments of code in which there would be a lot less questioning of amount of effort put in (since now separate), and just simply focusing on the correctness and input and output of particular objects in the code. This would indeed lessen the frustration of before.

In the next iteration I will plan to define the lines in which each of us does our work so that it's more independent but, in the end, is still overall correct. This will minimize frustration between partners. Both my partner and I underestimated the amount of time it would take to finish the project. We didn't think that there would be that many tokens to write code for and in my mind did not account for the amount of labor needed to type out each test case and comparison. In the next iteration we will make note to start as early as possible thus reducing the amount of stress in finishing it by the deadline. Other than that I do not feel that we need to change anything else. Since we have only done a single iteration, I am sure that other problems will arise in which we will address in the third iteration.

Although there were some problems in this iteration, the majority of the time things went smoothly. Our discussion on how to approach each situation seemed to be very effective. If we hadn't done this then most likely we would be uncoordinated, and possibly implement the same code fragments. Another effective technique was splitting up the labor of typing up the vast number of expressions and comparisons as well as their test cases. In the next iteration, we will definitely stick to these two techniques since it has been very successful thus far.

About this Archive

This page is an archive of entries from March 2012 listed from newest to oldest.

Find recent content on the main index or look in the archives to find all content.