Undergraduate Capstone Open Source Projects

Archive for the ‘Education’ Category


Posted by Greg Wilson on 2010/01/18

A couple of students have asked how UCOSP projects are graded. The short answer is, you tell us. Seriously—talk to your mentors and say, “These are the things I want to tackle, here’s why I think they’d be valuable and how much effort they’ll require, so please give me grades for X, Y, and Z.” If your mentor thinks you’ve chosen things that are too hard, too easy, or not particularly useful, the two of you can negotiate back and forth until you settle on something that makes you both happy. Based on previous terms’ projects, this works best if you follow a few simple rules:

  1. Define a handful of small tasks, rather than one big one. If 100% of your grade depends on flambulating the frajulator, and it turns out that fraulators are intrinsically unflambulable, you’ve got a problem.
  2. Work in small, steady steps, so that you can get feedback from your mentor (and change direction if necessary). We’re not going to set assignments every two or three weeks, but you should try very hard to deliver something—anything—every couple of weeks.
  3. But don’t wait a week or two to communicate with your team and mentor. Giving someone else feedback on the team mailing list or in IRC is a good way to take a break from a linear algebra assignment, and helps move the whole project forward.

One other thing that makes UCOSP different from regular courses is that we grade your work based on where you started, not on how much the rest of your team knew at the beginning of term. Some of you are working with languages or platforms you’ve never seen before, while others have done work terms with those same technologies. We’ve all been through that too, so your grade will be based on how far you get from where you are now. Long story short, don’t panic if you feel that everyone else on your team knows more than you do: it probably isn’t true, and even if it is, it doesn’t matter.

Posted in Education | 1 Comment »

Rich, Famous, and Popular

Posted by Greg Wilson on 2010/01/17

Almost everyone who joins a new project says it sooner or later: “More documentation, please.” No one can make sense of 30,000 lines of code in one gulp: everyone wants an overview or roadmap to help them make sense of things. So why don’t they exist?

  1. Almost by definition, by the time you can write that document, you don’t need it yourself. You probably also have a dozen tickets assigned to you by then too, all of which really, really need to be fixed for next week’s release.
  2. Overviews are much harder to write than lower-level Javadoc-style explanations of what individual methods do. The latter is just an assemblage of facts; the former requires story-telling skills, and good storytellers are rare in any field (not just programming).
  3. Anyone who ever has written an overview document knows that it will rust pretty quickly. Design decisions will change, code will be refactored, and pretty quickly, that 30-page tutorial you sweated over is so far out of date that it’s actually doing as much harm as good. Keeping it up to date is a never-ending struggle, and it’s not like people have stopped assigning you tickets…

Jacob Kaplan-Moss (from the Django team) wrote a good post a while back about writing great documentation. It’s worth reading, and he’s right: after a certain point, investing effort in documentation and discussion actually pays a bigger dividend for open source projects than investing effort in code. It’s still an open research problem, though; anyone who ever figures out how to generate, check, and update narrative explanations of how code is structured, what it does, and (most importantly) why, will be rich, famous, and popular. Lemme know how it goes…

Posted in Education | 1 Comment »

What We Expect From Students This Term

Posted by Greg Wilson on 2010/01/11

Titus Brown has started a wiki page describing what’s expected from the Pony-Build students this term, and I just posted to the Basie blog about what we didn’t finish last term, and need to get done in this one.  In brief, Titus’s points are:

  1. Communicate early and frequently.
  2. Make your work visible (if we can’t see what you’re doing, we can’t help you).
  3. It’s your responsibility to manage your time and make steady progress.
  4. Be friendly.

My points were more project-specific. Our immediate goal is to g et a usable release out the door in time for the Python Conference in mid-February, after which everyone will be free to work on riskier/more speculative things. We’re going to get there as follows:

  1. Every member of the team will post a punchline status report to this blog before they go to sleep on Monday. This post (from the MarkUs team) shows you what we’re after: Status, Next Steps, and Roadblocks, with bullet points for each.
  2. Everyone will read these reports before our online Tuesday meeting so that we can spend our time discussing technical issues.
  3. Everyone will put something up for review each week (even if it’s very small), and do at least one review each week as well.
  4. We’ll refresh the sandbox instance weekly so that we can always see what state the code is actually in (and, just as importantly, make sure that our install and setup instructions are up to date).

What are your project’s goals for the term? And how do you plan to get from here to there?

Posted in Education | Leave a Comment »

Never Just One Lesson

Posted by Greg Wilson on 2009/11/27

The official goal of this course is to give students first-hand experience of working in distributed teams. There are lots of other lessons to be learned, though, lessons that can only be learned by working on real applications. Take the performance bug that we just found in Basie, or the seemingly-simple problem of deleting tags (1, 2, 3, 4, 5, 6, 7). Neither is a coding bug: in both cases, we’re going to have to re-think a significant chunk of the system’s design. Problems like this just don’t come up in assignment-sized programs; as Simon Peyton-Jones observed in another context, scaling things up often changes their nature in important ways. It takes more effort for students to ramp up, but we think it’s worth it—do you?

Posted in Education | Leave a Comment »

What Grades Mean

Posted by Greg Wilson on 2009/11/21

We’re getting close to that time, so here’s the official definition of what grades mean in Arts & Science at the University of Toronto. If the scale at your school is significantly different, please let us know.

Percentage Letter Grade GPA Value Grade Definition
90-100 A+ 4.0 Excellent Strong evidence of original thinking; good organization; capacity to analyze and synthesize; superior grasp of subject matter with sound critical evaluations; evidence of extensive knowledge base.
85-89 A 4.0
80-84 A- 3.7
77-79 B+ 3.3 Good Evidence of grasp of subject matter, some evidence of critical capacity and analytic ability; reasonable understanding of relevant issues; evidence of familiarity with literature.
73-76 B 3.0
70-72 B- 2.7
67-69 C+ 2.3 Adequate Student who is profiting from his/her university experience; understanding of the subject matter; ability to develop solutions to simple problems in the material.
63-66 C 2.0
60-62 C- 1.7
57-59 D+ 1.3 Marginal Some evidence of familiarity with subject matter and some evidence that critical and analytic skills have been developed.
53-56 D 1.0
50-52 D- 0.7
0-49 F 0.0 Inadequate Little evidence of even superficial understanding of subject matter; weakness in critical and analytic skills; with limited or irrelevant use
of literature.

Posted in Education | 1 Comment »

Writing Great Documentation

Posted by Greg Wilson on 2009/11/16

Some of this term’s students are planning to produce documentation as part of their final deliverables, so a link to Jacob Kaplan-Moss’s ongoing series “Writing Great Documentation” seems in order. Hope it’s useful.

Posted in Education, Uncategorized | Leave a Comment »

Phil Agre on Getting Help

Posted by Greg Wilson on 2009/11/13

Phil Agre’s 1994 article “The Art of Getting Help” is still good advice…

Posted in Education | Leave a Comment »

Grading Schemes at a Glance

Posted by Greg Wilson on 2009/11/05

Here are links to each team’s final grading scheme:

I think that writing these is a more important part of the software engineering process than most students realize. A grading scheme is the academic equivalent of a contract of deliverables: it’s the thing that you and I can put in front of a judge or some other third part if we disagree over whether you’ve delivered what I thought was promised.  Some parts of these grading schemes, like 10% for playing well with others, don’t show up in such contracts because they’re just assumed: if you don’t play well, you don’t keep your job [1]. Many of the rest, though, are exactly what I’d expect as a consultant: feature X, able to do Y, tested by Z.  I’ve experimented in my regular software engineering course with having students write their own assignment specs, and the more I do it, the more important I think it is. I’m curious to know what the students themselves think…

[1] Unfortunately, this often isn’t true: I’ve worked beside people who were awful human beings, but somehow never got fired. There are lots of reasons why this happens; it’s a good subject for a future blog post.

Posted in Education | 2 Comments »

How to Write Code That’s Hard to Test

Posted by Greg Wilson on 2009/10/29

Google’s Misko Hevery has posted slides from the tutorial he gave at OOPSLA’09 on how to write code that’s hard to test. It includes a few hints on how to write code that isn’t, too 🙂

Posted in Education | Leave a Comment »

Theory AND Practice

Posted by Greg Wilson on 2009/10/29

There’s nothing like a bit of controversy to push up readership—and blood pressure. I inadvertently started it by describing UCOSP to Joel Spolsky at DevDays in Toronto last Friday. He thought that having undergrads work on capstone projects in distributed teams was cool—cool enough that he’s willing to sponsor the program and have one of his employees mentor a Mercurial project next term.

Browsing our blog, he came across my post “A Rational Response to an Irrational Environment“. It starts by explaining that it’s rational for students to leave assignments to the last minute, since (a) focusing on one thing for a day is more productive than timeslicing five things for a week and (b) the spec is likely to have settled down by then. It then speculated that students in self-managed project courses tend to push work off because there aren’t the same looming deadlines and fixed grading schemes.

Joel used that post as a launchpad for his own post “Capstone projects and time management“, which is a critique of university computer science programs. In it, he asks, “Where are students supposed to learn about version control, bug tracking, working on teams, scheduling, estimating, debugging, usability testing, and documentation?” and says that, “Many universities have managed to convince themselves that the more irrelevant the curriculum is to the real world, the more elite they are.”

A lot of poeple didn’t like that. In “Joel Spolsky, Snake-Oil Salesman“, for example, Mark Dennehy challenges #2: “…what Joel hasn’t mentioned—and what [CS] lecturers can tell you because they’ve been debating it for decades, writing papers on it, holding conferences and have published peer-reviewed journals on the topic…—are that there are very specific and very good reasons why CS … undergraduate courses don’t get to cover all the industry tools Joel uses.” Some of his claims are questionable (team projects are actually as useful for beginners as they are for more experienced students) and some are straw men, but two are spot on: it’s impossible to put everything into a four year degree, and “university courses are for [teaching] the fundamentals so that the students can pick up specific skills far more rapidly and evaluate tools according to their proposed use.”.

The basic problem is a circle that many disciplines (not just CS) struggle to square. On the one hand, we’re here to teach students the fundamentals of particular subjects—stuff that will still be relevant a decade from now, and that will allow them to innovate, and to digest others’ innovations. On the other hand, most of those students are going to enter the workforce once they graduate rather than pursue research careers, and most employers care more about debugging C++ than about NP completeness. It isn’t an either/or choice—understanding the big picture helps you understand why certain things work, and knowing how to apply concepts helps you understand them—but there are only about 4500 hours in a typical four-year undergrad program, so something has to give.

My position used to be very close to Joel Spolsky’s—in fact, one of the reasons I started supervising capstone projects back in 2002 was my frustration with new graduates’ lack of practical skills. I believe passionately that the better your are at programming, the deeper your appreciation for the theory of computer science will be, but it’s taken me a while to appreciate just how many practical skills universities do teach. Think about it: many first-year students have never programmed. You can argue that they should have in high school—or even that it should be mandatory—but we have to work with the reality we’ve got. By second year, those same students are malloc’ing memory and doing pointer arithmetic; in third year, they’re writing fork and exec, and in fourth year, they’re programming robots to play soccer and building Rails applications that are robust enough for real-world use. Can you imagine math departments trying to get people from “this is a fraction” to “this is a tensor” in those same four years?

Could our students get even further if we taught them less theory? It depends what you mean by “further”. Take out statistics, and they wouldn’t be able to analyze the performance of computer networks. Take out the semantics of programming languages, and they wouldn’t be able to understand what an optimizing compiler does. You could ask, “How many will ever need to?” but the point is we don’t know, so we have to try to cover as many bases as we can.

Technical colleges used to offer a more immediately practical alternative for those who wanted it (not just in computing). Sadly, over the past 25 years most have re-made themselves in the image of universities, primarily because of the higher social standing associated with a university degree. This leaves students who aren’t interested in the big picture nowhere else to go, and employers nowhere else to recruit.

Splitting computer science departments in two is not a solution. Even if we had departments and programs for “pure” computer science and others for “applied”, in the same way that there are separate departments for chemistry and chemical engineering, both sides would still have to decide how much time to invest where. And if you talk to professors in chemical or civil engineering, they’ll tell you they get the same complaints as CS.

Making undergrad degrees longer isn’t a solution either: even a five- or six-year program wouldn’t be able to do more than scratch the surface of an increasingly diverse discipline. And as useful as work terms are, they just bring forward the point at which students and employers run into the problem that we’re teaching red/black trees instead of C# delegates.

Spolsky’s praise for our cross-country capstone projects is immediately followed by the claim that, “…student projects, while laudatory, frequently fail to deliver anything useful.” In fact, about a quarter of the 129 student projects I’ve helped supervise since 2002 have delivered software that clients actually used, and the rest have produced something just as useful: experience. I think our students can be proud of that record, especially when you consider that a one-term course is equivalent to just three weeks of full-time work.

UCOSP is just one experiment of many—embedding students in ongoing open source projects, as David Humphrey describes in “Who are your peers?, also holds tremendous promise, as do the dozens of other ideas that people are trying out all over the world. The challenge now is to figure out how to scale these ideas up without heroic effort from either instructors or students. We’d welcome your suggestions.

Posted in Education | Leave a Comment »