When my partner and I were working on iteration 1 of the Where's The Forest?! project, I experienced some unique benefits and challenges that I did not experience when programming on my own. One benefit is that it is easier to solve problems and fix bugs because each person brings their unique skills and knowledge to the table. One challenge is keeping in contact with each other so each person knows exactly what they need to do, and what the other person needs to do.
The benefits of having two people write code instead of one have proven to be invaluable. When one of us didn't know how to write a section of code, the other person was able to figure out how to do it. For example, my partner figured out the regular expression for a line comment, which saved me some time. I was able to write the Makefile to compile our code on my own, so my partner was free to work on other things. Our combined effort made writing iteration 1 easier than it would have been on my own. To keep this synergy going, we will stay in contact with each other when we're working on future iterations. Whenever I get stuck on something, I can ask my partner for help, and he can download my code from our repository using version control software. I am confident that both of us will be able to solve any problem that arises.
A challenge of having two people write code is making sure both people know exactly what the other person is planning on doing, and making sure the code will be compatible. If one person makes a major change to the structure of a program, then the code that the other person writes may not work anymore. Because of this, I was hesitant to start writing code for iteration 1 right away. I didn't want to write a lot of code only to find out that my partner went in an entirely different direction that rendered my code useless. We resolved this problem by agreeing on the broad structure of the program before we tried to combine our code. We both decided how we would split up the functions into three separate .cpp files, and what exactly each file would do. This strategy worked very well, and we didn't have to spend any time fixing bugs caused by incompatible code. If everyone knows what functions will be in the program, then the details of those functions can vary a lot without changing the program. In the future, we are going to write all of the function prototypes ahead of time, before any code is written. That way, no matter how we write the code for a function, the input and output of that function will remain the same. Working on a piece of code together can be challenging, but it is very beneficial when there are open lines of communication and adequate planning ahead of time.
Connor Yorks
Cool, it sounds like you already figured out a nice way of dividing up the work well in advance. I haven't always been the best at sticking to the planned API. I tend to take a crowbar to things about halfway through the task.
Jon Sorbie
Your post is very positive and provides some suggest solutions. I think this time around I will try to start by going over design with my partner. And I completely agree with the communication part. Happy to hear that it's working out for you.
-Elsa Dosh
Oops! sorry about posting that 2X.
It's okay :)
I agree that deciding before hand exactly what each partner is responsible for is a good idea. During iteration one our group had a few instances where we ended up either working on the same thing or not working on something at all. In later iterations we will definitely follow a more design oriented format.
Lucas Sherman
You are right. We should frequently communicate with partner on our progress, to make sure there are not major incompatibility between our part and our partner's part. Otherwise a lot of time and effort will be wasted. Correction on the code can be painful with a complex and huge program.