Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!spf
From: spf@clyde.UUCP
Newsgroups: comp.edu
Subject: Re: software engineering
Message-ID: <7916@clyde.ATT.COM>
Date: Tue, 31-Mar-87 14:10:13 EST
Article-I.D.: clyde.7916
Posted: Tue Mar 31 14:10:13 1987
Date-Received: Thu, 2-Apr-87 00:38:50 EST
References: <340@ndsuvax.UUCP> <1986@cwruecmp.UUCP> <4428@utah-cs.UUCP>
Sender: nuucp@clyde.ATT.COM
Reply-To: spf@bonnie.UUCP (Steve Frysinger)
Organization: AT&T Bell Laboratories, Whippany NJ
Lines: 22

In article <4428@utah-cs.UUCP> shebs@utah-cs.UUCP (Stanley Shebs) writes:
>One radical
>solution might be to de-emphasize writing programs, and require reading them,
>starting with the first course.  I would be interested in hearing if anyone
>has tried making a first- or second-year CS class modify programs that were
>much too large for them to have written themselves...

Sort of.  In a first semester programming course, and a first course
in data structures and algorithm, my written tests generally have
only one small program or procedure to be WRITTEN by the student,
but three or four programs or procedures to be READ by the student.
With the latter, they would either have to write down the output
given the input, or find the syntax errors, or find the semantic/logic
errors.  This reflected my experience in the lab: people who can't
READ programs are pretty bad at WRITING them, especially when forced
to live with the error messages produced by the VM/CMS compiler (ugh!).

I will confess, it's also easier to grade objectively a reading
problem, rather than reading a student's program and grading it
subjectively.

Steve