Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site gatech.CSNET
Path: utzoo!watmath!clyde!cbosgd!gatech!spaf
From: spaf@gatech.CSNET (Gene Spafford)
Newsgroups: net.cse
Subject: Re: students editing output
Message-ID: <1264@gatech.CSNET>
Date: Mon, 16-Sep-85 16:10:54 EDT
Article-I.D.: gatech.1264
Posted: Mon Sep 16 16:10:54 1985
Date-Received: Tue, 17-Sep-85 06:09:39 EDT
References: <433@uvm-cs.UUCP> <2889@ut-sally.UUCP> <6293@duke.UUCP>
Reply-To: spaf@gatech.UUCP (Gene Spafford)
Organization: The Clouds Project, School of ICS, Georgia Tech
Lines: 60


Of course, we've touched on the fact that the style, structure, and
comments in student assignments are important.  I usually count a
significant portion of the credit on an assignment to the modularity
and readability of the code (because it is important to teach students
to code that way and because they are less likely to panic and do
desperate things if they know they can get credit for a partial
solution).

However, correct functioning is important.  If we produced only
graduates who were able to code with style but unable to produce
functioning programs, we would find few people would continue to value
our graduates.  Therefore, it is important that we produce students who
know how to complete a project and make it work.

Let me list some of the desired attributes of students I would
want to graduate from a programming/design course:

-- their code is well documented, both structure and algorithms
-- their code is modular and well separated functionally
-- their code is designed to be expandable without a total rewrite
-- their code checks for boundary and error conditions, and especially
    for bogus input
-- they test their own code


With those in mind, it is easy to see that we don't want to design
assignments where we tell the students ahead of time what the input and
output is going to be.  Rather, we tell them the format and kind of
input and the output we expect, both for valid input and for improper
input.

For example, after explaining the recursive algorithm for solving the
Towers of Hanoi problem, we could easily give an assignment to the
class telling them to implement a program to solve the problem for 5
disks and print the sequence of moves.  A much better assignment would
be to have them write a general program which would take, as input, the
number of disks from 1 to 10, as well as an indicator of which peg the
disks are on and which one to move the disks to, and then print the
sequence of moves.  After the assignment is done, we obtain a copy of
each student program and run it with preselected input data which
tests a few proper values, both boundaries, and some improper input (11
disks, -1 disk, 4th peg).  The students don't know the exact input
ahead of time so they can't take a short-cut to producing the output.
It forces them to think more about the problem and anticipate possible
input.  Plus, their programs are tested for more than just the solution
to one particular case -- they are tested to see if they are  valid
solutions to the class of problems presented.

That's how I address the problem of edited output.  I spend more time
defining the assignment so that the student isn't sure of the exact
output required.  I make the problem more general (and more like a
real-world problem in terms of input and output processing), and then I
run a copy of the program myself.  I think it teaches more.

-- 
Gene "3 months and counting" Spafford
The Clouds Project, School of ICS, Georgia Tech, Atlanta GA 30332
CSNet:	Spaf @ GATech		ARPA:	Spaf%GATech.CSNet @ CSNet-Relay.ARPA
uucp:	...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!spaf


Brought to you by Super Global Mega Corp .com