For most of your working life, you will need to work effectively in teams with other people. Developing good teamwork skills is important for success in this course, and for success in life.
Remember to treat your relationship with the other members of your team as a professional relationship, and things will go much more smoothly. Communication is key! If you make a commitment to your team, it is important to make every attempt to honour it. If, however, something comes up that makes it impossible for you to meet your commitments, then let your team members know as soon as possible so that you can all make alternate plans. This applies to group meetings, Subversion check-ins, and internal deadlines that your team sets for getting parts of the assignment completed.
In the rest of this document, we list some strategies for working together and using DrProject.
This is the first assignment that requires you to work in teams of two. This may be difficult if you are accustomed to working alone, but it is essential for the completion of the remaining assignments and is a worthwhile skill to develop in any case. These assignments are too complex to be done single-handedly, and you will gain valuable real-world experience from learning to work in a team effectively.
You and your partner will be working with a shared Subversion (SVN) repository, which has been set up through DrProject.
The remaining assignments are as independent as we can make them, but some parts of this assignment (particularly synchronization) will be needed in the future. Thus, decisions you make now will affect the remainder of your assignments. We suggest that you and your partner resolve conflicts about things like programming style and naming conventions now in order to avoid confusion later. Working together on a program can be much more demanding and frustrating than doing lab work together. (Imagine writing a coherent term paper with someone else!)
There are a number of issues that you and your partner should work out now, when things are calm, so you needn't figure them out at 2:00 AM in the heat of the moment.
Naming Conventions
It's a good idea to select some rudimentary protocol for naming global variables and variables passed as arguments to functions. This way, you can just ask your partner to write some function and, while s/he's doing it, you can make calls to that function in your own code, confident that you have a common naming convention from which to work. Be consistent in the way you write the names of functions: given a function called "my function", one might write its name as my_function, myFunction, MyFunction, mYfUnCtIoN, ymayUnctionFay, etc. Pick one model and stick to it (although we discourage the last two examples).
Subversion and DrProject Use
Since you and your partner will be using Subversion to manage your work, you will need to decide when and how often to commit changes. (Advice: early and often.) Additionally, you should agree upon how much detail to log when committing files. Perhaps more importantly, you also need to think about how to maintain the integrity of the system- what procedures to follow to make sure you can always extract a working version of some sort from SVN, whether or not it's the latest version, what tests to run on a new version to make sure you haven't inadvertently broken something, etc.
Clear, explicit SVN logs are essential. If you are incommunicado for some reason, it is vital for your partner to be able to reconstruct your design, implementation and debugging process from your SVN logs (NOTE: Outside of catastrophic injury, there is little excuse for you to not communicate with your partner(s). But just in case.) In general, leaving something uncommitted for a long period of time is dangerous: it means that you are undertaking too large a piece of work and have not broken it down effectively. Once some new code compiles and doesn't break the world, commit it. When you've got a small part working, commit it. When you've designed something and written a lot of comments, commit it. Commits are free. Hours spent hand-merging hundreds of lines of code wastes time you'll never get back. The combination of frequent commits and good, detailed comments will facilitate more efficient program development.
Use the features of SVN to help you. For example, you may want to use tags to identify when major features are added and when they're stable.
Use tickets as one form of communication. If you layout your tasks as tickets and work at breaking them down into smaller components, then your partner will be able to see at a glance where you are at and you will be better able to coordinate your work.
Communication
Nothing replaces good, open communication between partners. The more you can direct that communication to issues of content ("How shall we design sys_fork()?") instead of procedural details ("What do you mean, you never checked in your version of foo.c?"), the more productive your group will be.
If you decide to drop the course, please notify your parter as soon as possible, so that he or she can quickly find a new partner.
In your design documents for each assignment, you should identify, at least in general terms, who was responsible for the various parts of your solutions.
It takes effort to make a partnership work, and it is your responsibility to manage your partnership. If at any time during the course of the semester, you and your partner realize that you are having difficulty working together, please come speak with the instructor or one of the TAs. We will work with you to help your partnership work more effectively, or in extreme circumstances, we will help you find new partners.
Subversion is a source code revision control system. It manages the source files of a software package so that multiple programmers may work simultaneously. Each programmer has a private copy of the source tree and makes modifications independently. Subversion attempts to intelligently merge multiple people's modifications, highlighting potential conflicts when it fails.
Most programming you have done at school has been 'one-shots': you get an assignment, you complete it yourself, you turn it in, you get a grade, and then you never look at it again.
The commercial software world uses a very different paradigm: development continues on the same code base producing releases at regular intervals. This kind of development normally requires multiple people working simultaneously within the same code base, and necessitates a system for tracking and merging changes. Now that you are sharing code with your partner, you will find the features of Subversion are very handy.
Subversion is very powerful, but for CSC369 you only need to know a subset of its functionality. The Introduction to Subversion handout contains all the information you need to know and should serve as a reference throughout the semester.