Iteration 1

Overall, I was satisfied with the performance of our group on the Iteration 1. Even though we started late (about a day before the deadline), we were able to finish on time all the requirements and pass all the tests. I can give several reasons, which can explain why we accomplished Iteration 1 successfully. First of all, as a base for our implementation, we decided to use WordCount program from lab_03, which counted numbers and words. That program gave us the main idea about the overall structure of the code we needed to write. So, instead of starting from scratch, we employed the idea of code re-use, which probably has saved us a lot of time.

The second reason we did well on Iteration 1 was because our design followed the idea of splitting the functionality of the program into individual and logically independent modules. Each of these modules (in our case, they were the functions in class Scanner) was responsible for a single functionality. Testing and debugging such functions was easy and efficient.

Finally, we were able to create adequate testing scenarios, which helped us to evaluate the performance of the program and correct the errors whenever the tests cases were failing.

However, as I mentioned, the above description was my overall impression about the process. Going into more details, I can point to several problems, which our group would have to address in the following Iterations.

Since we started working on the project late, we did not have enough time to devote to design some of the functions in an efficient way. Moreover, our design and implementation did not follow the principle of writing the test cases first and only after that writing the code itself. Rather, what we have done was to assign to one of the partners a task of writing the test case, while the other one was writing most of the code. So, we worked in parallel and only were able to see the results of our work at the very end. Such a division of labor has also violated the principle that a single person must be responsible for creating the test cases, implementing the algorithm and testing and debugging it. What actually happened was that all the testing and debugging was done at the end.

The fact that we were able to find and fix all the bugs could simply be attributed to a pure luck. Given a larger and more complicated project, the above strategy of testing the whole code at the end would lead to many extra hours spent debugging. That could lead to a missed deadline and even to re-writing the code from scratch.

Beside the fact that we started late, the other factor, which influenced our performance on the Iteration 1 was not a very efficient collaboration. Each of us was used to work independently and the work in the group required extra effort of cooperation. Whenever all the partners agreed, the work went smoothly and there came the main benefit of collaboration - the work was done faster and in a better way than could be achieved if working individually. However, when there was a disagreement, then the work progress would slow down significantly. So, it seems to me that in order to achieve a better collaboration, the team members must be willing to compromise and accept the ideas given by the other partners.

In the following iterations, we will try start the work well in advance. This would allow us to anticipate and give enough time to fix any problems, which may occur during the future iterations. Moreover, we would have to do a better job on the separation of the work, so that a single person would be responsible for a part of the code, which he designed, implemented and tested (the tests, of course, will be written before the code itself). Finally, to be more successful and to get the full benefit of working in the team, we need to improve our collaboration.