The first of iteration of our project, called Where's The Forest, has been completed and development is going well. During iteration one, we were tasked with creating a scanner for a pretend programming language and to print out a list of tokens found within a file written in that language. If iteration one of WTF has taught me anything, it would be that working in a small team makes development life easier. Being the start of the project, iteration one had some repetitive code that was easier to deal with given an extra set of fingers, which allowed for the meat and potatoes of the iteration to be developed. On top of that, the different knowledge and experiences that my partner and I have combined to make code that will lay a solid foundation for the iterations to come, including methods we might not have implemented if we were in a single-programmer environment. We did, however, run into a small challenge with code sharing that isn't a problem for single programmer projects. This challenge is easy to outweigh with benefits of teamwork such as the division of boring labor.
One benefit that arose from working in a group of two people was the reduction in tedious tasks. During our implementation of iteration one, we created over 30 different regular expressions to match the different possible strings within the file to translate and each of these regular expressions had four lines of code to initialize. Just to deal with this single part of the code required over 120 lines of repetitive code that required little to no thinking after the regex pattern for each was created. (I would like to point out quick to any critics that might say "Loops are perfect for repetitive code" that each of these regexs were being stored into individual variables for possible later use. Using a loop would not have been possible for such design.) Having to write this over and over again (or even a continuous copy, paste and edit) takes away from the enjoyment of creating a good algorithm and can annoy the programmer, especially when working solo. Luckily, since I was working with a partner, we were able to divide up the code needed to be written so that development could quickly proceed past that section of code. To a seasoned programmer, 120 lines might sound like a small gripe, but what about when the code gets to be 200 lines or how about 300? I would gladly take the help writing such code to proceed onto better items. In the future, I hope we will be able to better plan out when such sections of code will arise, especially if that code will be larger than what we had to write during iteration one. With the number of different types of tokens required for the language in WTF, I expect more repetitive code will show up soon. Getting these lackluster sections of code completed will bring us faster to the development pieces that will require both of us to pool from our respective experiences.
Another benefit to working in a team that we came across was that diversity of knowledge can help overcome problems. My partner and I have not taken exactly the same classes nor have we had the same programming experience. I've had an internship as a software engineer where I've tackled real-world problems and he is farther in the Computer Science course curriculum than I am. Our differences bring a variety of views to our project. Two good examples come to mind. First, I have little experience with C and have only begun using it this semester but he used it during the spring. Due to this, he was able to see the opportunities to construct structs that were helpful in keeping track of data. If I had been working alone, I would have wasted time trying to figure out what I can do in C rather than actually getting farther in the iteration. Second, with my experience on large projects, I was able to modularize our code to make it easier to read and more maintainable. If my partner had not decided to develop iteration one that way when working alone, he would have run the risk of developing code that would be a hassle to change come other iterations of WTF. But if he was working alone, he would have saved time not having to worry about code sharing with a partner.
Yet even with benefits such as these, some people still find that team projects can be more of a hassle than working alone due to the sharing of code. During iteration one, we ran into this challenge when completing the repetitive code mentioned earlier. When we had both completed our portions of the repetitive code and tried merging them together, our version control system, Subversion, gave us an error message. As it turned out, I had changed a single line of code before beginning on the repetitive code while he used a text editor to do a find/replace that accidentally replaced a word in that same line I changed. Obviously, the version control system had no way of properly merging these copies of the file. Luckily for us, Subversion was able to show us exactly where the problem was and we were able to get it resolved quickly. As soon as you use a version control system that offers that capability, keep better track of your changes and better communicate the changes before sharing them with your team, few problems of this nature should ever arise.
With the second iteration soon to come, I can only be thankful for working in a team. My partner and I will better plan out our second iteration to take advantage of dividing up code that is repetitive or code that can take away from any enjoyment of developing WTF. We will also be sure to seek out any opportunity to use the distinct skill-sets we have gained to better develop WTF than if either of us had to do so separately. Unfortunately, we will have to be weary of sharing code that both of us have edited concurrently. However, if we better inform each other of changes and track them better, these challenges will rarely show up. Working in a group is a great advantage for programmers and practicing to work out the kinks now will be a benefit for any project to come.