On the importance of UCOSP

This past weekend I hosted the UCOSP code sprint at the University of Alberta. About 40 students and 7 project mentors came here for an intensive weekend-long session of software development.

UCOSP – the Undergraduate Capstone Open-Source Project – is a distributed software-engineering course that brings together undergraduate students across Canada (and sometimes North America) to work on open-source projects.

I have described the nuts-and-bolts of UCOSP several times to different people with different purposes, so I can easily give a short description of “how UCOSP works”, since I am hoping that some readers may consider participating.

From an administrative point of view, UCOSP is managed by a steering committee of three, Michelle Craig and Karen Reid at the University of Toronto and Eleni Stroulia at the University of Alberta, with support from a part-time administrator. It runs under the auspices of the Canadian Computer-Science Department Chairs.

Each semester, since the Fall term of 2008, a few (between five and ten) open-source projects are solicited and selected to join the UCOSP. Projects that participate in UCOSP should

• be open source,
• have an existing user community, and
• have a person willing to act as a mentor and team lead for a group of students.

At the same time, through software-engineering faculty in Universities across Canada, senior students are solicited to participate. These students register to related courses in their home institutions, usually independent-studies or special-project courses, with a supervising faculty. The steering committee associates students with projects, based on their preferences and background. During the term, the students work in the context of these distributed teams under the guidance of the project mentor, who, in the end, comments on each individual student’s work and performance and assigns a “grade” which, then, is submitted to their home institution by home supervising faculty.

In the beginning of each semester, UCOSP facilitates a “code sprint” week-end, where the students enrolled in the program travel to a central location and work on their projects with fellow team members and their project mentors. And this time, the sprint was at my home.

So now that I have the descriptive details out of the way, let me proceed to the more interesting part of the blog, and let me explain my position on why I think this is a terribly important, interesting and rewarding activity.

First off, on “why this is important”, I have to say that this is as close as we can get to the proverbial “real world”, in teaching software engineering. And making it real is terribly important from a pedagogical perspective. I am working with many colleagues in health-science disciplines who, at this point in time, are seeing a shift in their pedagogy model, from curriculum-based to competence-based. As a result, instead of defining the “required body of knowledge”, educators are defining “professional competencies”; correspondingly, instead of assessing students through traditional examinations designed to cover this or that body of knowledge, educators are turning to simulation-based methods for training and assessment, so that students should not have to demonstrate knowledge of facts and procedures anymore but rather their ability to bring this knowledge to bear in scenarios simulating the situations where this knowledge is relevant in real practice. I believe we (software-engineering educators) should be doing the same, namely develop simulation of the real practice, which is what UCOSP essentially is. This is the only means to actually train people to become competent in

• dealing with projects whose lifecycle does not coincide with the student project (all of our UCOSP projects exist outside UCOSP and some have long lifecycles and large developer teams within which the UCOSP student teams work),
• collaborating with team members (without relying on the bonds that usually come with belonging in the same peer group or class cohort),
• managing their personal agenda and synchronizing it with that of the project (without relying on well-defined deadlines for submissions that come with the well-defined well-scoped projects of typical courses and similar typical loads across the team members),
• dealing with unknown tools and languages that the project comes with (which is usually unheard of in projects of courses with well-thought out dependencies on prerequisite courses), and
• working across time zones (Canada has a special advantage in this dimension).

Second, on the “why is this interesting” question, I have to argue for its variety. The scope of software systems that are being developed by UCOSP projects is astounding. This term, we have a mobile application (on the Android platform) for biological monitoring applications, a couple of video recording/streaming/sharing systems, and two web-based tools. The students get the opportunity to explore conceptual and technical problems and technologies that cannot possibly be part of any four-year, or even five-year, undergraduate program. Clearly, it cannot be the objective of an undergraduate program to teach students all technologies, especially in a field so fast as computer science. Instead, it is our objective to teach students how to learn; and UCOSP gives them the ability to practice this “learning” skill and develop this competence, while at the same time adding “knowledge facts” on their CVs, which may make them more appealing to an employer down the road.

Finally, “this is rewarding” because it is actually quite fun! It is a bit of stress, matchmaking students and projects, aligning calendars and deadlines across schools, getting feedback on time to students and home-institution faculty supervisors, and – generally speaking – making sure that a standard (in terms of amount and quality) work is being done by each individual student in each individual project. On the other hand, students love it and appreciate the opportunity and the sprint itself is a blast! In our building we have a open atrium area and from the third floor I could see inside several breakout rooms on the second floor, where UCOSP teams were working. I could see silent teams “hacking”, I could see teams drawing on whiteboards, I could see teams skyping with some remote mentors, I could see teams laughing at jokes! The intensity of their working faces, the energy of their thinking “fights”, and the merriness of their fooling around was so exciting and so optimistic that I am charged for at least a week of drudgery… but I have not drudgery in my future so will bank it for the future!