Automated bogus research paper detection

By now, is there a person in the world who isn't familiar with the annual WMCSCI spamference and the bogus paper submitted and accepted by them in 2005? Well, technology has caught up, and now Nagib Callaos and the other folks who run this and similar conferences can click on the link from the title above to get information on automatic detection of bogus papers without all that messy and bothersome reviewing.

More on the best jobs

Following up on my previous posting about Money magazine ranking software engineering as the best job in America is the Reuters article linked from the title above. They've got more information about the methodology used, which seems to suggest that they didn't introspect very much regarding what produced their numbers.

For example, they list college professors second, but they lump together university and community college, part time and full time, tenure track and non-tenure track. The result, is a statistic that the average work week is 30 hours and the average number of vacation days is 31. But, as anyone who works in academia will tell you, full-time faculty work many more than 30 (or 40, or 50...) hours per week, and generally faculty don't get any paid holidays (other than national or state holidays). The low work week is probably a result of including part-time faculty, who I strongly suspect would like to work more hour but who can't (perhaps because their employers would then have to pay them benefits). I don't know where the vacation day figure comes from. Faculty typically don't teach during the summer, but then again they don't get paid then either, unless they have research grants (in which case they're working many more than 30 hours/week doing research).

On the other hand, flexibility and creativity assessments seem more reasonable. So, perhaps the frenzy of the dot com bubble being over, workloads and stress have become less of a factor in the software industry?

The best job in America

You may argue about the exact ranking, but not its presence in the top 10. It also ranks second in job growth rate. Of additional interest is the #7 ranking of computer IT analyst (ranked 7th also in job growth rate). Oh, and college professor is #2.

Drinking my own lemonade

In a previous post on 12/5/2005, I commented on one impact of lower CS enrollment: smaller classes. I was wondering what I would do differently in my Winter quarter class, given that there would only be a few students in it. Now that the quarter is over, I thought I'd comment on what actually happened.

The class in question was a combination of algorithms, discrete math, and object-oriented design and programming. I ended up with 8 students in the class. Instead of meeting in the regularly scheduled classroom, we met in my lab, which gave a cozier, more group-oriented atmosphere. I organized the class around a single project. I covered all of the material that I would normally have, but started each topic with a roughly 30 minute presentation given by each student.

Project

I initially left the project wide open to student input; I would have been perfectly happy with any project they proposed, as long as it exercised the various topics we needed to cover. Failing that, I proposed what eventually turned out to be a simplified version of del.icio.us, except using hash tables, AVL trees, red/black trees, and graphs -- instead of databases -- for the back end. The project eventually developed an architecture with a back-end server (the bulk of the project) responding to CGI application requests. It actually is quite a nice job; I'm just waiting for a couple students to finish a "story of the project" web page (which I indicated was beyond the scope of the course itself) before making the URL public (just for looking; I won't leave the server running).

Project management

I am by nature a pretty hands-off person. It was not my goal to micro-manage the project, and in fact I would have been happy to have the students do everything. However, I couldn't make that a requirement of the course, as it wasn't a project management course. Instead, I gave them a lot of leeway, and if they didn't take up the slack, I gradually tightened things up and prescribed what they would do. So, at first things were wide open, even including the project itself. Then, I specified the overall project goal. I later led an in-class design exercise, and broke the project down into subsystems and tasks and farmed them out to teams. So, step by step, I produced more specific directions on what would be done, by whom, and when. Eventually, we had all of the elements you'd expect of a project: milestones, interface documents, version control, team meetings, group meetings, weekly reports (with required reflection on successes, failures, what they were doing right and wrong, and what they'd do differently the following week), code reviews, etc.

Certainly, I could have done all of this from the start -- it's how programming assignments would normally be done in CS classes -- and more could have been accomplished. but I think there's value in students being given a chance to do something, see that one approach doesn't make much headway, and then see that an alternative given by me works. I think, as long as you don't allow things to get too chaotic or students to get discouraged, this is better than laying everything out at the start. We were still able to accomplish all of my essential goals, and that's all one can really hope for in one quarter (did I mention yet that the quarter system sucks?).

Presentations

I developed a rubric for grading student presentations and summarized it in my syllabus. These are undergraduate presentations, and so they of course can't be expected to be up to the level of presentations in a graduate seminar. Beyond the experience itself, it helped to give me clues regarding what topics to cover in more detail.

All in all, I was pretty happy with the class' results. I'm not sure I would recommend this approach in a class with more than eight students. I suppose there could be multiple, smaller groups, but how crazed would it be to have multiple, large (all quarter or semester long) projects ongoing? Generally, I don't like group projects (I do one in a class every so often to remind myself why I don't like them), but the length of this one and the number of students helped mitigate many of the negative issues.

Take home message: size does matter. Smaller classes are better.

Topics: academia, computer science.

[+/-] show/hide the rest of this post