TITLE: An Experiment with Students Creating Examples
AUTHOR: Eugene Wallingford
DATE: September 26, 2008 5:24 AM
DESC:
-----
BODY:
A couple of weeks ago, I mentioned that I might have my
students
create their own examples
for a homework assignment. Among the possible benefits
of this were:
- helping the programmers to write down their understanding
of the problem in a concrete way early in the process
- giving the programmers a way of to ask concrete questions
early in the process -- and reason to ask the questions
- helping the programmers know how much code to write and
when to stop
I tried this and, as usual, learned as much or more than my
students.
Getting students to think concretely about their tasks is
tough, but asking them to write examples seemed to help.
Most of them made a pretty good effort and so fleshed out
what the one- or two-line text description I gave them
meant. I saw lots of the normal cases for each task but
also examples at the boundaries of the spec (What if the
list is empty?) and on the types of arguments (What if the
user passes an integer when the procedure asks for a list?
What if the user passes -1 when the procedure expects a
non-negative integer?) In class, before the assignment
was due, we were able to discuss how much type checking
we want our procedures to do, if any, in a language like
Scheme without
manifest types.
Similarly, should we write examples with the wrong number
of arguments, which result in an error?
I noticed that most students' examples contrasted cases
with different inputs to a procedure, but that few thought
about different kinds of output from the procedure.
Can filter return an empty list? Well, sure;
can you show me an example? I'll know next time to talk
to students about this and have them think more broadly
about their specs.
Requiring examples part-way through the assignment did
motivate questions earlier than usual. On previous
assignments, if I received any questions at all, they
tended to arrive in my mailbox the night before the
programs were due. That was still the case, but now
the deadline was halfway through the assignment period,
before they had written any code. And most of the
class seemed happy to comply with my request that they
write their examples before they wrote their code.
(They are rarely in a hurry to write their code!)
Did having their own examples in hand help the students
know how much code to write and when to stop? Would
examples provided by me have helped as much? I don't
know, but I guess 'yes' to both. Hmm. I didn't ask
students about this! Next time...
Seeing their examples early helped me
as much writing their examples early helped them. They
got valuable feedback, yes, but so did I. I learned a
bit of what they were thinking about the specific problems
at hand, but I also learned a bit of what they think
about more generally when faced with a programming
task.
My first attempt at this also gave me some insight about
how to describe the idea of writing examples better, and
why it's worth the effort. The examples should clarify
the textual description of the problem. They aren't
about testing. They may be useful as tests later, but
they probably aren't sufficient. (They approximate
are a form of
black box testing,
but not
white box testing.)
As clarifiers, one might take an extreme position: If
the textual description of the problem were missing,
would the examples be enough for us to know what
procedure to write? At this extreme, examples with the
wrong number and type of arguments might be essential;
in the more conventional role of clarifying the spec,
those examples are unnecessary.
One thing that intrigued me after I made this assignment
is that students might use their examples as the source
material for test-driven development. (There's that word
again.) I doubt many students consider this on their
own; a few have an inclination to write and test code in
close temporal proximity, but TDD isn't a natural outgrowth
of that for most of them. In any case, we are currently
learning a
pattern-driven style of programming,
so they have a pretty good idea of what their simplest
piece of code will look like. There is a nice connection,
though. Structural recursion relies on mimicking the
structure of the input data, and that data definition
also gives the programmer an idea about the kinds of
input for which she should have examples. That s-list
is either an empty list or a pair...
I'm probably reinventing a lot of wheels that the crew
behind How to Design Programs smoothed out long
ago. But I feel like I'm learning something useful along
the way.
-----