Before taking this class I did not have much experience in writing large programs, and I had never collaborated so closely with someone else while writing one. So, writing the scanner portion of our language translator was quite a learning experience, and, naturally, there were some problems, but overall I feel as though everything went well. I will be using this post to document my experiences with this iteration so that I, or anyone else interested, may know what worked well for me, as well as what didn't.
This was the first time that I had worked on a large project with another person, so this part made me the most nervous. This is the first class I have taken at the U, so, since I didn't really know anyone that well, I had to let fate decide my partner for me. Luckily fate was kind, and I was paired with someone who was skilled and who worked hard, but we did face a big problem early on; our schedules were wildly different. He was busy all throughout the week but was free on weekends, while I had nothing but time during the week, but no time on the weekends. This forced us to spend more time working individually than I would have liked.
We did manage to make time in our schedules to meet up, however. When we did we spent a lot of time planning out what each one of us would do individually. We worked out the architecture of the scanner, decided who would work on what component of the scanner, and who would write what test. Of course we spent time coding together during these meetings too, but that was secondary. Outside of these meetings we communicated through email or phone when we needed to discuss something and used Subversion to share the code that we had written. Overall I believe that we worked very well together, and hopefully that will continue once we begin work on the next iterations.
The way we planned to work on this iteration was simple. We were to write the tests for a component of the scanner, then code that component of the scanner. We would then write tests for another component of the scanner, and so on. In practice, however, only a few black-box tests were written before we wrote each component. It wasn't until after we finished coding that component that we would go back and write more thorough white-box tests. I believe that if we had written more black-box tests beforehand we would have better understood how to write each component, which is something that we did struggle with slightly. A perfect example of this hurting us was in the creation of the regular expressions. At first we didn't realize that we had to have tests for each individual regular expression, and neither one of us thought to do that anyway. So the result was us only discovering that a regular expression was incorrect when our scanner failed other tests. It wasn't until we finally got all of them working through this time consuming and indirect way of doing things that we found out that we had to individually test each one. So in the end we wasted even more time writing tests that didn't help, but that would have helped immensely had we written them earlier.
Another mistake that we made was our time management. We didn't start any serious work on the scanner until less than a week before it was due. While this wasn't as bad as it could have been, this still caused us to have to rush certain things, and it caused us a lot of unnecessary stress. We also ended up working right until the very end. We didn't turn in the final complete tag of iteration 1 until less than ten minutes before the due date. Despite this we did manage to get everything done on time to our satisfaction, but it is still something that I want to do differently in the future.
Our process wasn't all bad, however. Despite the way we wrote the tests, they still helped immensely. Before this class the only experience that I had testing my code was using a debugger and by using print statements. Using test-driven development and the cxxtest framework did help everything go a lot more smoothly, and it is something that I plan to use in the future, both inside and outside of this class. Also, even though we weren't able to get together much, I feel that when my partner and I did meet up we were very productive. It helped that we always had a clear idea of what each of us should do, and Subversion was a lot of help when we were working individually.
This is the first time that I have used Subversion or any kind of version control software though, and, despite my inexperience, I think we used Subversion well overall. It was a very helpful way for us to share our code, but we did have one problem that both my partner and I were guilty of. When we were working individually on some component of scan we had a tendency to not commit our code until we had it working. This did cause some confusion, since if one of us was struggling on a certain piece of code and wasn't ever committing it, then it would appear that that person was not working on anything. For example, my partner planned to do major work on the scan function the Wednesday before the iteration was due, but late Wednesday night nothing was up on the repository. I wasn't able to get a hold of him, so I ended up writing it myself. When we met up the next day I learned that he had worked on it, but struggled a bit and never committed what he had done. In the end we had written two different scan functions, which obviously was a waste of time.
We used Subversion well besides that one incident, though. It is a very convenient to save your code and to share it with others, and I hope that I get to use it or other version control software in the future.
Overall I feel that this iteration went very well, or at least as about as good as could be expected. We waited for too long before beginning work on it, our use of test-driven development left a lot to be desired, and our use of Subversion wasn't perfect, but those problems were outweighed by positives. We worked well together, and most of our development practices worked quite well. Most of all this iteration has acted as a learning experience, and we will, hopefully, learn from our mistakes and continue doing what worked well.
First, we need to make sure to write thorough tests before we begin work on the actual code. I believe that this will make things go much more smoothly in the future. Second, we should also start committing all of our work to Subversion, even if we can't get something to work quite right. Since it is so easy to simply roll back to another revision with Subversion, we shouldn't be worried about messing anything up, and committing our code more often should help both of us better understand what we're doing when we aren't able to meet up. Third, and most importantly, we need to begin work on the iterations sooner. Waiting until there are only a few days left to start coding is both stressful and risky. But this will probably be the hardest thing to change, as I've been a procrastinator for my entire life. Hopefully the reward of not having to deal with all of the stress associated with procrastination will be enough to make me change my ways.
To continue doing what worked well, we should continue using our meetings to plan the architecture of our program and decide on what work we will both do before the next meeting. I feel that this part of our plan worked very well, and it is something that I hope we continue. My schedule will be changing in the next few weeks to one that more closely resembles my partner's, so we may be able to meet up more often while working on future iterations. We should also continue to work using test-driven development because, despite the problems we had, it was invaluable to our completion of the scanner.
Hopefully putting down all of my thoughts in one place like this will help me better remember the lessons I learned, so I can apply them in the future. Thank you for reading this post, and hopefully this will also help you with anything you may have struggled with.