lac at openend.se
Fri Mar 21 07:54:48 CET 2008
In a message of Thu, 20 Mar 2008 21:49:39 -0400, Richard Enbody writes:
>We randomly assign within assigned labs -- the labs have 16-20
>students. We assign within labs because there is a time, the assigned
>lab, when students can meet. That is, the excuse "we couldn't meet" is
>not valid. On a subsequent assignment we roll the dice again within the
>lab and ensure that the same two do not pair up again. If a partner is
>a 'no-show' we allow them to match with anyone else who is also paired
>with a 'no-show'. We have considered various matching schemes, but if
>I remember correctly, random is supposed to be the best way -- as
>opposed to trying to match students.
16-20 is considered oversize if you want to get everybody pairing with
everybody, so I would partition my class into 3 groups of 6 or 8
(or maybe 2 groups of 8 for the 16 case), and then build a rotation schemee
for each group, not getting the groups to interpenetrate. Random isn't
exactly what you are looking for. When people say that it is better
to partner randomly, what they mean is that you need a mechanism to
keep people who like working together from doing just that. But simple
randomness isn't going to ensure that everybody gets to pair with everybody
unless there are a really large number of sessions for 'changing pairs'.
I've got some more questions:
How long do you have to work with these people? How long is a lab,
and how many rotations do you try to fit into a lab? and How long
is a course, and how many labs in a course? How much work do you
expect people to do on the programs outside of lab time? Are the
labs self-contained, or do they build on each other's work?
>We know about the 'driver' and 'thinker' roles and that the students
>should change roles. We talk about it with students, but do not try to
I've always had problems with that concept -- or rather, with the idea
that the 'driver' is the one doing the typing, and the 'thinker' is
the one doing the watching. Some students I know think a lot better
when they are typing than when they aren't. Some students who aren't
typing pretty much dictate what the typer is going to type. So I don't
know if I am just doing something wrong, or if the model is unrealistic.
>I like your model, but it would be difficult to implement here -- too
>many students have too much going on (unfortunately, for many that is a
>job to help them get through school).
I have this problem, too, which is why we mostly can only experiment
with things like that in Summer courses, and camps, where you are
trying to pack what would normally be taught in 4 months or 8 months
into 2. And still there are some people who cannot make the time.
>On your question about not having marks -- that isn't an option. On
>your question, 'what if 85% got 85%?' That would be great! Our grading
>scheme is not competitive -- if you get the points, you get the grade.
>In theory, everyone could get a 4.0 (A). My understanding is that you
>need such a scheme for pair-programming to succeed. However, with
>enough students we seem to get a spread out distribution.
This is an indication that your weaker students aren't catching up
enough. The question is, why? If you are trying to get rotation
through groups of size 16 or 20, that is probably one contributing
factor. If the assigment runs out before the students who began
working on it can get back to it for a second pass, while having done
other things in the meantime, then that is another factor. There are
others I have seen, and some I have only heard about, such as trying to
do pair programming and not doing test driven design. Are you doing
that, as well?
>These questions have got me thinking!
>enbody at cse.msu.edu
More information about the Edu-sig