Reflecting on iteration 1
In this iteration, I and my lab partner were supposed to build a scanner that scans the sample texts, i.e. source code, generating a list of tokens from the texts. We started the iteration by writing tests. Then, we built the scanner based on the previous lab experiences. Now, I want to focus on the three challenges we encountered, how we coped with it, and what was the consequences of our actions. Finally, I will end up with suggesting several ways of making the next iterations successful.
[ Challenge One: Version Control ]
Because I and my partner were not familiar with using a version control system, we spent a considerable time on learning Subversion to get used to the version control system. Later, we both could be able to use the various useful SVN commands comfortably such as adding, modifying, deleting, and merging files on our repository. By using SVN to interact each other saved a lot of time. The feature I personally liked was tagging. This made me feel safe with starting a new iteration because I know I can always check the first iteration version of files. Also, using bash script for tagging was very practical! I appreciated that I did not need to type the repository address and the routine commands again and again.
[ Challenge Two: Specification ]
The next challenge we encountered was the fact that we didn't exactly know what we want to build. The iteration specification did not explain each step in detail like other project I and my lab partner experienced. After few hours of hovering, we decided to start from writing the tests. According to what we learnt in the class, writing test cases should help us on clarifying the problem we encountered. We, then, were happy to figure out what we want to do next. However, the point of this part is that we didn't write the test for the smallest functionality, but the largest functionality. This is because the goal of writing tests at this time was not to test the code, but to know how to code. Therefore, the tests we wrote were not tests for the unit testing, but more likely tests for the integration test.
[ Challenge Three: Dividing Work ]
In general, working with my lab partner was successful in that each of us contributed on the iteration, taking the same amount of workload. I was so glad to have a partner who is passionate about working together to successfully finish the project. However, we overlooked the importance of assigning works; we simply divided our work by coding and testing. The way of dividing work became the biggest reason why my group failed on finishing the iteration on time.
Although we distributed the workload very well, we could not divide the work itself very well. Dividing the whole thing by the same amount in the files level was not a wise choice. Since one of us has more experience on writing code while another has testing work experience, we thought we could save time if we do whatever we do better. Because testing that we planned to conduct was black box testing, the one who wrote the tests did not actually need to spend time on understanding the code, but only on focusing the expected results. Also, because the amount of testing for every token was numerous, the one who wrote code did not need to spend time on generating the huge amount of tests. At the end, we had scanner and tests done by each other. We ran the tests, and then, failed all of our test cases. Because there were no testing during coding, testing was not very profitable on finding the part where the scanner gone wrong. After spending substantial time, we figured out that the code was buggy from the most basic part. We, thereby, confirmed dividing the work by coding and testing was not a great idea for the iteration.
[ What's next? ]
For the successful further iterations, I firstly want to develop my skill of using SVN, for example, by using bash script not only for tagging, but also for observing the logs. Since I already experienced the power of version control system, I want to utilize it as much as possible. Moreover, I felt understanding the given problem as soon as possible before I jump into writing code is crucial. Therefore, I want to spend more time on reading the specification and discussing it with my partner. Drawing the big picture by writing tests also worked, but I think I need to be able to start writing the lower level tests, which is for the smaller functionality, as soon as I catch which functions will be implemented. Furthermore, I should be able to distribute the work by the method level instead of the file level, i.e. testing and coding level.
