🚀 go-pugleaf

perry@apollo.HP.COM (Jim Perry) writes:
>
>Students can't learn to make a good product if they don't know what one is.

Excellent point!  And, of course, most introductory textbooks do not
give particularly good examples.  Not because the authors are necessarily
bad designers, but because the constraints of teaching a 1st year student
Pascal/Modula/whatever mean that the programs emphasize micro-concepts
(this is an IF, this is a WHILE, etc.).  The commenting strategies also
reflect these realities -- anyone who really wrote comments the way
textbooks show them should be shot.  for an excellent discussion of
these issues, see Henry Ledgards "Professional Software" books (Vol. I
on Software Engineering and Vol. 2 on Programming Practice.  Vol. 2
has a chapter titled "Comments: The Reader's Bridge," and while I disagree
with some of Ledgard's specific examples, I do like his overall philosophy
of appropriate internal documentation.

So perhaps in 2nd level courses the professors should make available
programs they consider well-written.  In fact, I'm teaching a sophomore
course on design and implementation, and students have asked to see *my*
solution to some of the assignments I've given (and yes, I *do* solve
most of the problems, something that I find all too rare).  The problem
for me is that it is difficult to come up with assignments
at this level, and I know that my solution would immediately find its
way into every fraternity's archives (1/2 :-)), rendering it useless
in the future.

>One possibility that seems somewhat promising: in a class which has a longterm
>ongoing project (a compiler, perhaps), have students swap off source code at
>each iteration, so each increment of change is to someone else's code.

I've tried this one, and I've been disappointed.  Roughly speaking there
are two types of students: those who have good designs (class G) and
those who have bad designs (class B).  Let's look at the possibilities
at iteration 2:

For students in class G, no further motivation to do a good job is necessary.
No matter what they get, their predisposition to doing a good job will
be reinforced.  However, if given a bad product from stage one, they
feel they are penalized (and given the short time spans for projects in
a quarter or semester, they are right).  The general reaction is "I did
a good job, why do I have to work with this crap!"  Those who can recover
often end up doing two iterations: a rewrite of iteration 1 and whatever
is required for iteration 2.

Now consider students in class B.  If given a good design from iteration
one, they have a better shot at completing iteration 2, but the question
remains whether they learned anything about their own substandard performance.
In effect, this subidizes their poor work (we call it "hiding in the high
grass" around here).  On the other hand, if they are given a poor design,
their demonstrably modest skills means they have a small chance of completing
interation 2 on time.

If I truly believed that all students in class B were inherently incapable
of becoming productive, competent professionals, then the scenario above
wouldn't bother me -- the good would pass, and the poor would fail.  And
no doubt many of those in class B shouldn't enter our profession, either
because they lack the discipline or particular talents needed to succeed.
But in my experience, there is a substantial subset of class B who just
haven't caught on yet, and I don't want to flush them out.

One approach I haven't tried is a "bidding" approach, where everyone's
product from stage one is made available to the class. A small portion
of the grade for iteration 2 would be tied to the number of people
in the class who chose *your* solution as the basis for the next step.
In this way, everyone sees a variety of designs, they get to choose
the one they'll use next time, and the "recoverable" B students would
choose someone else's G work simply to save their own necks.

Has anyone tried something like this?

Mike Lutz
Mike Lutz	Rochester Institute of Technology, Rochester NY
UUCP:		{rutgers,cornell}!rochester!rit!mjl
INTERNET:	mjlics@ultb.isc.rit.edu