About

Software development is no longer bound by time zones or national borders. Projects of all kinds—academic, commercial, and open source—may have their GUI designers in Boston, their database team in Bangalore, and their testers in Budapest and Buenos Aires. Working effectively in such teams is challenging: it requires strong communication skills, and makes proper use of coordination tools such as version control and ticketing systems more important than ever. But it is also an opportunity for students to build ties with peers across the country and around the world, and for instructors to breathe new life into old courses.

Since September 2008, undergraduates from several universities in Canada and the US have been taking part in joint capstone projects in order to learn first-hand what distributed development is like. Each team has students from two or three schools, and uses a mix of agile and open source processes under the supervision of a faculty or industry lead. This FAQ describes the program’s current incarnation; if you have other questions, please contact Greg Wilson.

What are the learning objectives of this program? For students to gain hands-on experience with real-world development practices in a realistic environment while simultaneously learning and applying some core concepts of computer science.

Is this part of an official university or government program? Not yet—we are still in the pilot phase (which is a professor’s way of saying, “We’re still learning how to do this.”).

Who is sponsoring this? Our sponsors page describes and thanks the companies and organizations that have helped to make this program possible.

What projects are available? Our project list for Winter 2010 is available on the Projects page.

Who can enrol? Undergraduates who are in their final four terms of study, have a strong ‘B’ or ‘A’ average, and are able to enrol in an appropriate course at their home institution. (Typically, this course is called a capstone, a senior project, or a directed studies course.) To ensure balance, we limit the number of students per school; please contact your local faculty for details.

What schools are taking part? The following schools are confirmed for the Winter 2010 term:

• University of Alberta: Eleni Stroulia
• Michigan State University: Titus Brown
• Minnesota State University: Steven Case
• Simon Fraser University: Ted Kirkpatrick
• University of British Columbia: Meghan Allen
• University of Toronto: Greg Wilson
• University of the Virgin Islands: Steven Case
• University of Waterloo: Michael Godfrey

See the Fall 2009 page for a list of schools that took part in that term.

Can I still take part if my school is not in this list? Sure, if you can persuade a faculty member at your school—please have them contact Greg Wilson for more information.

Can I take part more than once? Sure, if you can persuade a faculty member at your school. If you do come back, you can either stay with the same project or move to a new one.

Who chooses what projects students work on? The students themselves, on a first-come, first-served basis. We try to make sure that each team has roughly six students drawn from at least three universities. We also try to have at least two students from any university on any one project so that everyone will have a local partner.

How are tasks within a project allocated? This varies from team to team. In general, though, there’s enough work for everyone to spend most of their time working on something they find interesting.

What skills do students need? The programming skills required vary widely from project to project: students are more likely to succeed in a Java-based project if they already speak Java, and more likely to do well on a cellphone project if they have some previous experience with handheld devices or wireless networks. Students should also be familiar with, or willing to learn, version control, bug tracking, and other coordination tools. Keep in mind, though, that being able to set their own goals, manage their own time, and communicate with others is at least as important as knowing any particular programming language or operating system.

What do students find challenging about these projects? Cooperation, communication, and commitment. For many students, this is the first time they have had to set their own goals and deadlines, and some struggle with that freedom during the first few weeks.

What are the benefits to the students? Experience working in a distributed team on a meaningful project; peer contacts (social/professional networking); something cool to demo in interviews for jobs and graduate school.

Do potential employers and graduate supervisors actually look at these projects? Yes.

When do projects start and finish? Projects start at the beginning of term (September or January), and run to its end (December or April). Because different schools calendars’ don’t line up, some students may start or finish earlier or later than others. We do not currently accommodate students whose schools use a quarter system, and have no plans to run this program during the summer.

How much effort is expected from students? The same as any other course, i.e., about 8-10 hours/week.

Can I do this course at the same time as a co-op job or other industry placement? Only if your school’s policy permits it, and even then, only if you can commit 8-10 hours/week.

How are projects managed? The organizers take care of week-by-week project management, though other faculty are very welcome to get involved as well.

How are projects graded? Grades are awarded jointly by the local faculty organizer in consultation with the project lead. Grading schemes are tailored to individual teams and projects, and take into account the requirements of the courses in which students are officially registered. (For example, a student who is registered in a senior course on Software Architecture may spend more time on design and documentation than on coding.) In many projects, students themselves propose grading schemes once they are familiar with the project. There is usually not a midterm or final exam, but some schools require students to do an end-of-term presentation and/or create a screencast to show what they have accomplished.

What development process do teams use? Standard software development processes are not well-suited to students’ realities: unlike professionals in industry, students usually have to work on several projects at once, and are almost always new to the technologies they’re using and the problem domain they’re working in. Based on past experience, the best fit is a mix of open source practices and Scrum:

• Every project keeps its work in a version control repository, uses tickets to track work items, etc. Teams are strongly encouraged to do code reviews.
• Each team has an hour-long online meeting each week to review progress, set goals, answer questions, and resolve outstanding issues.
• Work is usually done in two-week iterations. At the end of each iteration, each team member sets their goals for the next one, so that students have a chance to develop planning and estimation skills.
• Each team is required to produce a five-minute screencast demo of their work at the end of the term.

What kind of work do students do? All the things that real software projects need, including design, construction, testing, packaging, and documentation.

Do teams get to meet each other and their project leads? Yes—there is a three-day code sprint in Toronto near the start of term at which teams meet in person to discuss the strategies for the term, attend team-building social events, and write lots of code.

How do team members communicate? Via the usual online tools, such as blogs, chat, mailing lists, and Skype. Team members may agree on something else new and trendy, such as FriendFeed, Twitter, or Google Wave.

What level of work is expected? (Almost) all of these projects are producting software for real-world use, so standards are high. Remember, “95% correct” may be an ‘A’ academically, but if 5% of an application is buggy, users aren’t going to be happy.

Do the projects vary from term to term? Yes, although we try to keep projects rolling for several terms to reduce startup overheads.

Do students get help from students who have worked on the same project in previous terms? Yes, where possible. Unlike most university courses, we strongly encourage students to communicate with each other and their predecessors.

How do code reviews work? Students post finished work (including tests) to their team’s code review site. Another team member then reads it through and gives the author on what needs to be fixed before it can be committed. Once the author has made all the fixes suggested, and the reviewer gives the ok, the code is put into the version control repository for others to use.

How can I find out more? Please contact Greg Wilson or the organizer at your university for more details.