Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!ihlpg!drk
From: drk@ihlpg.UUCP
Newsgroups: comp.edu
Subject: Re: software engineering
Message-ID: <3076@ihlpg.ATT.COM>
Date: Tue, 31-Mar-87 08:57:59 EST
Article-I.D.: ihlpg.3076
Posted: Tue Mar 31 08:57:59 1987
Date-Received: Thu, 2-Apr-87 04:33:22 EST
References: <340@ndsuvax.UUCP> <1986@cwruecmp.UUCP> <4428@utah-cs.UUCP>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 24

In article <4428@utah-cs.UUCP>, shebs@utah-cs.UUCP (Stanley Shebs) writes:

> larger programs.  We had the idea of making the students change and extend
> some programs from week to week, so as to encourage data abstraction.
> What a failure.  Wired-in constants, gigantic case statements, you name it,
> somebody did it, even after numerous exhortations to the contrary.

I wonder if this was really a failure.  Unfortunately, one of the best ways
to learn is from your failures.  If people see from actual experience how
their wire-in constants, gigantic case statements, etc, cause real problems
when they try to extend their programs, then it seems to me that half the
battle is won.

To extend this idea of program modification, why not tell students they will
have to modify their first version of a program as a second assignment so
they should do the best job of structuring their program initially.  Then
make them modify it and run into all of the problems with modifying programs.
Then make them go back and rewrite their initial version of the program.
Then make them do another modification.  Seems like this could be very
effective.  In particular, those who do a good job initially, spend the 
least amount of time on the class.
						Denis Kertz
						AT&T Bell Labs
						Naperville, Ill.