Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!seismo!mimsy!brillig!beth
From: beth@brillig.UUCP
Newsgroups: comp.edu
Subject: Re: software engineering
Message-ID: <6172@mimsy.UUCP>
Date: Tue, 7-Apr-87 13:03:19 EST
Article-I.D.: mimsy.6172
Posted: Tue Apr  7 13:03:19 1987
Date-Received: Sat, 11-Apr-87 00:28:26 EST
References: <340@ndsuvax.UUCP> <1986@cwruecmp.UUCP> <427@applix.UUCP>
Sender: news@mimsy.UUCP
Reply-To: beth@brillig.UUCP (Beth Katz)
Organization: U of Maryland, Dept. of Computer Science,
Lines: 49
Keywords: changing other's programs

>Dan Pierson (...!decvax!frog!halleys!applix!dan) asks:
>Has anyone tried to drive home the importance of design and documentation by
>forcing students to significantly modify someone else's project?  This could
>be done either by trading projects in mid-course or by giving students in one
>course the final project from a previous (possibly different) course as a 
>starting point.

Yes, last spring as part of a course called "Software Design and Development
with Ada", my students modified two programs.  The purpose of the project
was two-fold (at least).  First, as part of my dissertation, I am trying to
evaluate the effects of design techniques on modularity and the effects of
modularity on maintainability.  Second, it seemed to be a good way for the
students to get their hands on bigger pieces of code early in the class. 

The programs (a text formatter and an electronic mail system) were written
by graduate students as part of the study.  We used four text formatters
and three mail systems in the maintenance study.  Each student changed one
version of each program.  I seeded a fault to cause a particular failure
in each system.  We asked the students to repair the fault (given a
failure report) and make two enhancements.

This project isn't quite what Dan had in mind.  We didn't give the students
the design documentation.  However, the project did drive home the importance
of meaningful variable names, sufficient in-line documentation, appropriate
modularity, and a vague idea of 'what Ada programs should and should not be'.
I would like to think that their group projects were better than they
would have been because the students did this maintenance work.  The 
students didn't like the programs all that much, but they thought the
project was useful.  [As an aside, as far as I know, they didn't cheat.
They knew I was monitoring what they were doing and that I was on the
machine quite a bit.  They also knew that their friends didn't necessarily
have the same program to change.]

In retrospect, I would give the students better programs to modify.  I
believe that reading good programs is one way of learning how to write
good programs (must be my literature upbringing).  But how many of us
have changed absolutely horrible programs?  It is an enlightening
experience.  Maybe I would give them one of each.  But the underlying
purpose of giving the programs the way we did was as part of the
experiments for my dissertation.  As a purely educational exercise, I'm
not sure which approach I would take.

				Beth Katz
				Dept. of Computer Science
				Univ. of Maryland - College Park
				beth@brillig.umd.edu

ps. The results from this should be available in a reasonable form
sometime this summer.