Undergraduate Capstone Open Source Projects

Archive for August, 2009

Code Sprint Sept 25-27

Posted by Greg Wilson on 2009/08/18

Thanks to the generosity of our sponsors, we are going to bring all of the students taking part in these projects together in Toronto Sept 25-27 for a three-day code sprint. This will give teams a chance to get to know each other in person, and to firm up their goals for the term. I’ll post more details about travel and accommodation arrangements as we have them.

Posted in Uncategorized | Leave a Comment »

Team Sizes

Posted by Greg Wilson on 2009/08/18

The roster is filling up:

Project UofA MSU SFU UT UT Scar Waterloo UBC UVic Total
Basie 1 . 2 2 . . . . 5
Eclipse4Edu 1 . . . . . . . 1
ElmCity . 2 . 1 . . . . 3
MarkUs . . . 1 1 2 . . 4
RoboCup . . 2 3 . 1 . . 6
Thunderbird 1 . . . . . 1 . 2
WikiDev . . 2 . . 2 . . 4
TBD . 1 . 1 . 1 . 1 4
Total 3 3 6 8 1 6 1 1 29

Posted in Status | 3 Comments »

Software Engineering as a Human Activity

Posted by Greg Wilson on 2009/08/15

The previous post touched on the need for more emphasis on evidence-based results in software engineering. This is a rapidly growing area of research—many of the papers at this year’s International Conference on Software Engineering (ICSE’09) presented, included, or referenced experiments or field studies of one kind or another.

Alongside this, there is growing interest in software engineering as a human activity, which has led many researchers to look at fields like social psychology. Some findings that might be particularly relevant to undergraduates working in teams touch on:

We will look at a handful of selected results during this course.

Posted in Education | Leave a Comment »

Bad Habits (and More Than a Little Marketing)

Posted by Greg Wilson on 2009/08/15

Following up the theme of the previous post on habits, this article discusses ten habits developers have to break in order to be successful with Scrum (a popular agile development methodology). A lot of the author’s points are good ones, but others are straw men set up just to be knocked over.  For example, “Traditional project management is very stubborn about setting the project plan and sticking to it no matter what,” is a caricature of engineering-style project management. Or take his very first rule:

Often, on traditional projects , team members create trails—written proof to cover themselves. Scrum…values communication and collaboration among team members. Individuals are encouraged to pair with other team members, discuss the story or task at hand, and drive it to completion (and not worry about getting it in writing). Team members must unlearn the mentality of creating a trail and learn to trust and depend on their teammates

Let’s take that one apart:

  1. People working in traditionally-managed projects also value communication and collaboration—implying that they don’t (without actually saying so) is just marketing spin.
  2. People working in agile projects who have problems with colleagues or partnering organizations also often keep records, and for good reason: if you ever have to go to your boss (or a lawyer) and say, “It’s their fault,” you have to be able to back it up.
  3. People working in both kinds of projects should keep records of what was said, by whom, and why, so that newcomers to the project can find out why things are the way they are. Remember, you can’t google a verbal conversation six months later when you’re trying to remember why the highest and lowest values in the array have to be discarded before calculating the average…

The most important thing in this article for me, though, is the complete absence of what anyone in business or science would accept as evidence. If someone tells you that a particular medicine reduces the risk of heart attack in diabetics, you expect them to be able to back that claim up—in fact, you expect them to present their evidence along with their claim without being asked.

Similarly, if I tell you that we’ll sell more candy if we put it near the front of the store, your first question ought to be, “How do you know?”  If I say, “Well, it’s obvious,” you’re perfectly within your rights to ignore me from then on. On the other hand, if I say, “We tried it in eight of our nineteen stores and sales went up 22%,” that shows that I’m doing more than blowing hot air.

We’ll be looking at this issue more closely during the course. In particular, we’ll be looking at what constitutes evidence in software engineering, and what we actually know about what works and what doesn’t. If you’d like to get a jump on this, check out Facts and Fallacies of Software Engineering, and then ask yourself how the information in it should shape the way we build programs.

Posted in Education | 2 Comments »

Why Good Has to be a Habit

Posted by Greg Wilson on 2009/08/15

A new study shows that the more stressed you are, the more likely you are to rely on habits instead of thinking through what’s best for your actual situation. (OK, it actually shows that for rats, but it’s easy to believe that the results apply to human beings as well.) As Dave Rooney explains in a recent blog post, this is why you have to drill and drill until doing the right thing is your habit: if you don’t, then when the going gets rough, you’ll revert to your earlier (and probably less productive) training, which will then increase your stress, and down you go. One of the goals for these projects is to shift everyone to good habits as early in the term as possible, even if they seem like overkill at the time, so that when the end-of-term crunch arrives, things won’t fall apart.

Posted in Education | 1 Comment »

Are We Done Yet?

Posted by Greg Wilson on 2009/08/15

One of the questions programmers often ask (and are often asked) is, “Are we done yet?” It’s often hard to know: unlike spaghetti, you can’t just throw software against the wall to see if it sticks. “When we run out of time” and “when we run out of money” are common answers in the real world, but there are better ways, and this page shows one of them. Each row represents a module in Firefox; the numbers show what percentage of the lines and functions in that module are exercised by tests. The goal definitely isn’t to get 100% coverage of every module—that’s usually impossible, almost always uneconomic, and still doesn’t guarantee that the program will work [1]. It’s also misleading to think that high coverage automatically means high reliability [2]. What it does do is draw attention to places where we just don’t know what the quality of the code is. As a bonus, if coverage from past test runs is stored somewhere, tables like these can tell us if the percentage of tested code in a module has suddenly gone down, i.e., if someone has added several hundred lines of new functionality without adding corresponding tests.

So why aren’t coverage stats like these taught in first year programming courses and expected afterward? Setting up a server to run tests automatically every hour and refresh a page like the example is a bit of work, but IDEs like Eclipse can equally well measure and report coverage on the developer’s desktop.  As with many other working practices, I think there are two reasons:

  1. Inertia: we didn’t do it twenty years ago, so today’s teachers don’t think it’s a must-have, so they don’t teach it to today’s students, and around and around we go.
  2. Time pressure: every undergraduate curriculum (not just that of computer science) is already overcrowded. As simple as this idea is, adding it would mean less time for something else, and no one can agree on what “something else” to take out.

[1] See Wikipedia’s discussion of code coverage and path coverage.

[2] Particularly for concurrent code—even if every individual path works correctly, the interactions between multiple processes or threads can cause race conditions, deadlocks, and partial failures.

Posted in Education | Leave a Comment »

More Information on Thunderbird

Posted by Greg Wilson on 2009/08/14

From Blake Winton, the main technical contact for the Thunderbird project:

For this term, I think students will be working on a Django (Python) site to manage the ISP configuration information for Thunderbird. There may also be some Javascript work to hook in to whatever pieces need to be added to the database.

To quote David Ascher (who’s in charge of Mozilla Messaging):

From a student project POV, especially given the schedule (fall, when we’ll be locking things down in TB3), I suspect getting them working on the Django site that powers the database that manages the autoconfig data would be an interesting idea. Easier ramp up curve (a fairly straightforward Django app), some interesting problems (distributing trust, auditable records, email security).

Next term, there will probably be something to make the database more decentralized, which would be largely javascript-powered. (Basically check for the configuration values in places like “http://autoconfig.domain.com/mail.xml?domain=domain.com” for an email address of “me@domain.com”, and then fall back to the Mozilla Messaging servers if that doesn’t exist.

To quote David again:

We’re also happy (likely after TB3, so maybe in a student project) to consider something more decentralized, so that an ISP (or meta-ISP like TUCOWS) could themselves manage the data storage based on some agreed upon domain, kinda like the Exchange autodiscovery model (but simpler =).

Posted in Thunderbird | Leave a Comment »

More Information on ElmCity

Posted by Greg Wilson on 2009/08/14

Jon Udell has put up a blog post with (much) more information about the ElmCity project. As he sees it, there’s scope for both a general calendar data scraper, and a hybrid system for finding information about recurring events and making it explicit.  Lots of room here to do a lot of creative things…

Posted in ElmCity | Leave a Comment »

Recommended Reading

Posted by Greg Wilson on 2009/08/08

We’ve added a “recommended reading” page to this blog with pointers to books that participants might find useful.

Posted in Education | Leave a Comment »

25 and Counting

Posted by Greg Wilson on 2009/08/08

We’re pleased to add three more students to our fall roster from the University of Alberta in Edmonton. That brings the number of participating schools to six, with four more in the wings. And Blake Winton, a freelance software developer in Toronto, is now on board to mentor our Thunderbird project.

Posted in Status | Leave a Comment »