Having finished the first iteration of our class project, I feel like I've already learned a lot about how programming works in a "real" setting. Prior to this class, the majority of the programming I have done was alone. There are some nice things about programming an entire project alone from start to finish. You have a bit more freedom to implement things how you think they best make sense. You can use data structures that you prefer and stay away from ones you don't like as much.
However, it's unrealistic to think we'll always be able to have it that easy. Real complex programs are made by large teams of people. Even going from solo programming to a team of two is a big change in how things must be done. For me, this presented some challenges especially in the earlier stages of the project. However, I found that these challenges actually ended up being large benefits over the course of completing the iteration. For example, when working solo, one can get by without a lot of planning and design. It is a bit easier to jump straight into coding, and fix problems as they arise.
Completing a project alongside another programmer, we were forced to do more planning before we could start implementing. We each had ideas for how we could approach the task at hand, but some of those ideas overlapped. In order to avoid stepping on each other's toes, we had to decide together on some of the larger design elements of the project before we could actually start coding.
At first progress felt a bit slow, as we were unsure how to begin. We started building in some functionality that we had discussed, and quickly realized how we could break this functionality down into smaller parts. This is where testing actually became something I was not only enjoying, but also heavily relying on. In the past, I have been more inclined to write small "print" statements throughout my code, and then verify that the output of these is what I expect. With a more robust testing suite, and smaller code performing one function at a time, it became much easier to see what needed fixing or improvement.
As we begun our work, we were able to fall into a good rhythm of alternating who was working on the code. My partner would make some changes during the day, and I would come home after work and review these changes. We would notify each other of our intent by leaving detailed comments, and helpful messages when committing to our group repository. We met every couple days to look at the progress we had made, and see if there were areas we could make improvements, and gave ourselves tasks for the next couple days.
This process worked quite well for us for the most part, with only small frustrations encountered. At one point, a change I made passed our tests with no errors on my own personal computer, but failed the tests on the lab machines. My partner found this out while I was at work and was unable to assist in tracking down what was causing the error. This difference of schedules made it a bit trickier to meet and investigate problems like this as they arose. This also pointed out to us that testing on the lab computers as soon as possible is important to continuing work.
As a version control tool, SVN worked very well for us. We were able to benefit from a lot of the features of version control that were talked about in class, such as rolling back to a previous revision, and merging our separate changes into one revision.
In the future, we will likely continue a very similar development process to what we have used so far. Due to our schedules, it is unlikely we will actually work together at the same time on the code more often than we have been. However, I think as long as we know each other's intent and talk about design before implementation, this process works just fine. As long as we make a better effort to test frequently on the lab machines, we should be able to avoid excess work on fixing bugs and other issues. We also may benefit from meeting a bit more frequently to review our work.