UCOSP

Undergraduate Capstone Open Source Projects

Archive for the ‘Education’ Category

Forty Years After

Posted by Greg Wilson on 2009/10/27

Communications of the ACM has published a reflective article by Sir Tony Hoare in which he looks back forty years to one of the foundational articles in computer science.  It includes a lot of interesting snippets, including this:

The phenomenon that triggered interest in software verification from the software industry was totally unpredicted and unpredictable. It was the attack of the hacker…

Well worth reading…

Posted in Education | Leave a Comment »

All Together Now (Or Not)

Posted by Greg Wilson on 2009/10/25

By the end of this week (Oct 30), each of our teams has to propose a grading scheme they’d like used for their term’s work. To do this, they’ll have to decide (a) what they’re going to deliver by Friday December 4 (our target wrap-up date) and (b) how much of their grade will depend on the team’s accomplishments, and how much will depend on individual contributions. Experience shows that the latter is much harder to decide than the former: most people want their grade to reflect what they’ve done, but clients care about what’s delivered as a whole.

I can’t tell students how to make this decision [1], but I can suggest that everyone read Oakley et al’s paper “Turning Student Groups into Effective Teams“. I can also suggest that teams think about grading schemes they’ve had in other courses that they thought were ambiguous or unfair, and try to make sure that what they hand in on Friday doesn’t have those faults: I’ve always hated things like “software is adequately tested: 10%” because I never knew what the prof meant by “adequate”.

[1] Well, I could, but that would defeat one of the main aims of the course…

Posted in Education | 7 Comments »

My Tools of the Trade

Posted by jerboaa on 2009/10/22

Here’s a list of tools I cast essential for carrying out my day-to-day business or I find otherwise useful.

Hardware (in no particular order)

  • My primary workstation is a HP Pavillion Slimline, a pretty much standard, off-the-shelf PC on which I installed Ubuntu Linux. The hardware works reasonable well under Linux, but at some point I wish hardware vendors would just offer some models which work seamlessly with any major OS. Anyhow, the desktop has 3 GB of RAM and 500 GB hard disk. Nothing really special, it does it’s job and is about a year old, now. It is complemented by a 21” Dell LCD monitor and the other usual peripherals. By the way, once you’ve used laptops for your daily work for so long that you don’t even realize how small your screen actually is, you will appreciate the decently sized monitor of your new desktop.
  • Other than my desktop computer, I use an Asus eeePC netbook when traveling or at my office at work or at university and sometimes my old Toshiba laptop I run Debian on. The netbook has very decent Linux compatible hardware. Mainly because it came with some Linux preinstalled – I guess is was some weird Xandros. That wasn’t quite it for my netbook – I found it very limiting – so I installed Ubuntu on it using the array.org custom kernel and the netbook remix software package. This works reasonable well for me.

Software (in no particular order)

  • Linux (and the various standard *NIX tools): I like open-source and I like to have the opportunity to debug my OS, so I’m using Linux (Debian and Ubuntu) for the most part. I found it frustrating at times when I was a Windows user and something stopped working from one day to the next. Although it was mostly me why things broke, I still had no reasonable way of undoing/fixing things. Well, at least not nearly as nicely as I can fix and analyze things on my Linux boxes. My mind wanders…
  • Gnome Terminal: Bash to be precise. I’m using Bash on a daily basis and I don’t want to live without it anymore. It just helps getting your work done.
  • Screen: A quite handy tool for multiplying your screen when working remotely on a machine via SSH.
  • Mozilla Firefox: The first thing I’m starting once logged on to my computer is a Web browser. No matter if I’m debugging some CSS or asynchronous HTTP request or if I’m just reading my favorite paper, Firefox is the tool of choice.
  • Firebug: Number 1 Web developer tool. I haven’t seen a better tool, yet.
  • Ad-block Plus: The online world is just not bearable without it.
  • It’s all text!: This one is also a quite handy add-on if you were to write text/code in HTML textareas a lot. By using It’s all text! you can load the content of any textarea into your favorite text editor (GVIM in my case), edit it and save it back into the appropriate textarea of the Web page.
  • Vmplayer and qemu: These tools are just nice for the occasional boot into a clean Linux sandbox or testing some IE stuff on Windows. I use qemu to create the bare vmdk disks and use vmplayer to play them. VirtualBox is also a nice alternative.
  • Eclipse (with RadRails, and other plugins): When doing some programming in Java, Python, Rails or C I use Eclipse for the most part augmented with quite a few VIM here and there.
  • VIM: For writing Latex, BASH scripts, code  or for any other use of plain text processing, VIM is my tool of choice.
  • XChat: My preferred X IRC client
  • Evolution: A quite reasonable choice for doing all my email work. I chose Evolution, since it has a calendar integrated, but I’m not sure if Mozilla Thunderbird with Google Calendar wouldn’t work quite as well.
  • Latex: Either for writing articles, assignments, theses. It’s simply a nice layout.
  • Inkscape: Sometimes when there some vector drawings to create (such as the MarkUs logo :-))
  • GIMP: For my very basic image manipulation needs.
  • OpenOffice.org: For the occasional word processing or spreadsheeting.

I think these are (most of) my all-time-favorite tools. What are you using? What do you find helpful?

Here are some links what other people wrote about this topic: Mike Gunderloy and 1, 2, 3, 4, 5, 6, 7, 8, 9, and counting…

Posted in Basie, Eclipse4Edu, Education, ElmCity, Ingres, MarkUs, RoboCup, Thunderbird, WikiDev | Tagged: | 5 Comments »

A Rational Response to an Irrational Environment

Posted by Greg Wilson on 2009/10/21

Four years ago, I asked one of the best students I’ve ever had why she always did her projects in one big burst of activity starting at the last possible minute. She explained to me that (a) she was more productive if she focused on one thing at a time, rather than trying to timeslice on three or four assignments at once, and (b) the later she left it, the more stable the assignment spec would be, because the keeners that started early would have pestered the prof into correcting the inevitable omissions, ambiguities, and what-not. In short, doing things the “wrong” way was actually a very rational response to an irrational environment.

I’ve seen a different sort of “rational response” in project courses like this one. Other courses have assignments with set weights and fixed deadlines, so on any given Tuesday, a student working on Basie or WikiDev has to choose between putting hours into a 10% stats assignment that’s due on Friday, or putting those same hours into—well, into something that could probably be pushed back a day or two. Or three. Or into next week, because once stats is out of the way it’s time to catch up on operating systems, which is due on Monday. And then there’s the AI midterm, and the outline of the term paper for the psych course that turned out not to be as easy as everyone had said, and around and around it goes.

Now, if we (the mentors for the UCOSP projects) had been parceling things up into bite-sized chunks and setting specific due dates, I’m confident that almost everyone taking part would have done the work, and done it well, by our deadlines. But we’re not doing that, because one of the points of this course is to give you a chance to find out what it’s like to set and then meet your own goals. The net result is pretty clear at this point: in many cases, students are doing less per week on this course than they would on a more structured course that had exactly the same content. It isn’t that anyone is deliberately slacking; it’s just that the fixed deadlines in other course always seem to be looming up out of the fog, and it’s very hard to choose to put them out of your mind and work on something whose panic point is further off.

It’s hard for us as instructors to figure out how to address this (which is a prof’s way of saying, “I don’t know what to do.”) Micromanaging students the way they’re usually micromanaged defeats the purpose of this course, and almost certainly makes it more fun. Asking students to specify each week what they will have completed a week hence doesn’t work well either: what does the prof do when the student says, “I will have written some tests for the module I’m working on” three weeks in a row? If the prof says, “Enough: if they aren’t checked in by next Thursday, I’m taking 5% off your course grade,” then we’re right back into traditional assignment-based micromanagement (or even worse, since the “assignments” are being sprung on students at unpredictable intervals). We haven’t yet found something that works well; suggestions would be welcome.

Posted in Education | 21 Comments »

A Lesson from “Coders at Work”

Posted by Greg Wilson on 2009/10/21

Over the last four or five years, there’s been a dramatic increase in the number of books about programming: not the specifics of this language or that framework, but the act of programming itself. Fogel’s Producing Open Source Software, Spinellis’s Code Reading, Ford’s The Productive Programmer, Doar’s Practical Development Environments, and multi-author collections like Beautiful Code and Beautiful Testing all discuss the things that separate people who can write code that compiles and runs from people who can build useful software.

The most recent entry in this category is Seibel’s Coders at Work, which collects his interviews with 15 great programmers. I haven’t finished it yet, but two things keep jumping out at me. The first is the importance of getting things into users’ hands as early as possible. It doesn’t have to be finished, and it certainly doesn’t have to be perfect; as long as it does something—anything—that they find useful, they’ll start giving you feedback. No matter how smart you are, you can only foresee a small fraction of what people will actually want to do, or how they’ll want to do it; letting them drive your software around is the best way to get the early course corrections that can save you days or weeks of wasted effort.

The second thing that jumps out at me is how focused these programmers are on avoiding waste—or rather, on delivering value. Will adding this feature or refactoring that module make the user’s life better in the near term? If not, file a ticket and move on, because there are plenty of other things that will. No, you shouldn’t let too much technical debt pile up, and yes, there are times when writing another abstraction layer will make development of the next dozen things so much faster that you’ll be ahead overall, but you have to know both your users and your code very well to be sure of that payoff. It’s all to easy to go from, “I want to fix this bug,” to, “Hm, I should refactor these classes first,” and then to, “Well, if I’m going to do that, I should upgrade this library,” and, “So first I’ll patch my OS,” until you find yourself three hours later saying, “OK, so once I’ve shaved the yak…”

So does this mean people should just hack together whatever works today with no thought for tomorrow? Of course not. Well-written code is its own reward, and one of your goals as a professional should be to make the right way of doing things a habit so that you won’t make silly mistakes when you’re tired, stressed, and up against a deadline. As an inveterate yak-shaver, I’ve found it helpful to always ask someone by email, “Should I be doing this?” before I start anything that’s going to take more than half an hour. At the very least, it keeps my teammates up to date with what I’m working on, and more often than you’d think, someone on the team will say, “Actually, wouldn’t it be more productive for you to do this other thing instead?”

Now, if you’ll excuse me, I need to go milk a whale…

Posted in Education | 9 Comments »

I Keep Quoting Jason Cohen…

Posted by Greg Wilson on 2009/09/29

…or at least referring to his articles.  He recently posted twice about an important topic: getting feedback. Everyone who wants their software to be used should read both carefully (yes, that means you).

Posted in Education | 2 Comments »

It’s a Bit Early for a Post Mortem…

Posted by Greg Wilson on 2009/09/28

…but we did one anyway, since the code sprint marks the end of the startup phase of our projects.

Good:

  • the code sprint was held early in term
  • everyone got to the sprint, and got a much clearer idea of what their project is about
  • effective initial training (for some projects)
  • good collaboration
  • a chance to learn how to use version control and other professional tools for real
  • the talk about grad school was informative
  • good workspace for the sprint, and the network ran flawlessly
  • enjoyed pub night(s) :-)

Bad:

  • ragged start: wasn’t added to mailing list, didn’t know project objectives, didn’t have access to version control repository/tickets, etc.
  • installing and configuring software to get started on project was difficult
  • first meeting with teammates didn’t happen soon enough
  • not enough variety in projects (7/8 are effectively web development)
  • not clear what recruiting criteria were
  • overindulgence at pub night(s)

The next step (other than filing expense claims) is due at the end of October, when teams and individuals have to tell us how they want their work evaluated in December. As we said in the post mortem meeting, it wouldn’t have been fair to specify that at the start of the term: neither the students nor the project leads knew then what was possible. Four weeks from now, though, everyone should have a clear idea of what their targets are, and how to tell if those targets have been met. We have a lot of work in front of us, but it’s going to be a lot of fun too…

Posted in Education | 1 Comment »

Why Teams Fail With Acceptance Testing

Posted by Greg Wilson on 2009/09/27

Good post from the author of a good book about why and how teams fail when using acceptance testing.  Thanks, Adam.

Posted in Education | Leave a Comment »

Yahoo! Hack Oct 13-17

Posted by Greg Wilson on 2009/09/27

Yahoo! (one of the sponsors of UCOSP) is organizing Hack Days at several universities around the world, and you’re invited.  It’s Toronto and Waterloo’s turn October 13-17: guests will include Rasmus Lerdorf, creator of PHP, and Douglas Crockford, famous for JSON, JavaScript, and much else.  Hope to see you there…

Posted in Education | Leave a Comment »

Overcoming Barriers to Self-Management in Software Teams

Posted by Greg Wilson on 2009/09/26

As I’ve written earlier, an increasing amount of research in software engineering is focused on empirical studies of what actually works (or doesn’t) in the real world. A new paper from Moe, Dingsøyr, and Dybå reports a multi-year study of teams in several companies implementing Scrum. Key problems they identified include:

  • Over-specialization: if each module “belongs” to one developer, it’s hard for the group as a whole to design and plan, because no one knows enough to get a big picture view.
  • Unclear completion criteria: if team members don’t know how to tell when something’s done, it’s difficult for them to plan and prioritize.
  • Meetings that are not engaging: self-explanatory.
  • Lack of team autonomy: in particular, if managers constantly come along and say, “Never mind the plan, fixing this bug is now your top priority,” people stop caring about making plans in the first place.
  • Impression management: if managers give their managers the impression that a team is better than it actually is, then the team will be given goals that are impossible to meet.
  • Resource contention: developers who are working on two or more projects in parallel always have to decide who to disappoint.  (Note: students are usually working on five courses at once…)

The paper suggests solutions for all of these problems, but they basically come down to “use common sense”.  It’ll be interesting at the end of term to see which of the traps on this list we’ve fallen into, and whether we can improve next time ’round.

Posted in Education | 1 Comment »

 
Follow

Get every new post delivered to your Inbox.