They say: "All's well that ends well". One might argue, however, that a great ending is judged not only by a great result, but by the path that was taken to get there. Iteration 1 is complete, and the results are in! On the big spectrum, Iteration 1 is only the beginning of a long process that will result in the completion of the project. Therefore, it is extremely useful to look at the development of Iteration 1 in order to ensure that the rest of the project can have a good ending as well.
Testing, testing, and once again, testing! We discussed its importance in lecture throughout the entire semester thus far, but somehow the concept went missing as soon as the actual coding started. Of course, we were forced to find it again, but maybe too late to prevent a few long struggles to find misbehaving code. This iteration stressed the importance of creating the test cases as you write a segment of code, or, preferably- before the code is written. Adding lines upon lines of code, followed by their test cases doesn't work so well when you realize that a test case isn't passing, and you have no idea what change caused the bug. Thus, unit testing was one of the most important ideas that was relearned throughout the process of creating Iteration 1. Writing test cases for little bits of code before writing the code itself ensures that you understand what exactly it is that you need to create. Then, if something just happens to mysteriously fail (Why would it fail, it's impossible that I made a mistake!), you have a good idea of what piece of code made the error occur, and it doesn't take as long to fix.
Lack of testing (although I definitely am not recommending it) can actually sometimes be a good thing- if you have a good partner. Having errors in your code definitely increases communication and encourages good partner work. Working together to figure out the errors and mistakes in the code allows for both people to really understand all parts of the code, including the parts that the other person coded. Also, having errors in the code means that they have to be fixed- introducing you to the successful moment of "YES! It WORKS!!!" The definition of teamwork itself requires a shared workload. This requires careful planning of timing and schedules to ensure that one partner doesn't do too much of the work. If both partners can't work on it at the same time, there should be some guidelines as to what one partner can accomplish before handing off the code. Throughout Iteration 1, my partner sometimes had time to work on the code at an earlier time than I did, making catching up to make my contribution a bit difficult. However, in the end, we were able to decently share the workload. All in all, working in pairs for this iteration turned out to be a great success!
The next iteration is going to increase in its success level. The beginning of the journey to the completion of the project has already taught us many lessons of how to make the next step flow smoothly. Lecture covered unit testing, the concept was re-established through mistakes while completing iteration 1, and it will be well on its way to perfection in iteration 2. Working in pairs was effective, and teamwork will continue to be important in the next step of the process. "All's well" when we recognize our mistakes, fix them, and continue to improve on what was already successful. We're well on the path to "ends well".