Path: utzoo!utgpu!water!watmath!clyde!att-cb!ucbvax!husc6!umb!rouilj
From: rouilj@umb.umb.edu (John P. Rouillard)
Newsgroups: comp.software-eng
Subject: Re: Soft eng in 1st yr classes.. pontification
Message-ID: <624@umb.umb.edu>
Date: 1 Apr 88 21:22:58 GMT
References: <555@psu-cs.UUCP> <1434@ur-tut.UUCP> <3415@bunker.UUCP> <5359@utah-cs.UUCP> <36845UH2@PSUVM> <563@psu-cs.UUCP> <1167@pembina.UUCP>
Reply-To: rouilj@umb.UUCP (John P. Rouillard)
Organization: Dept of Math and CS, UMass Boston.
Lines: 67


SALT  (all line eaters need salt on their food)

My background in computer science has no grounding in academia.  I
have worked side by side with other programmers who have B.S.
degrees (or are working toward (seniors)) in computer science.

     The following three things are what I consider the most important
aspects of programming for industry.

     I often find that these students CAN'T program modularly, CAN'T
give estimates of the amount of time that a project will take,  and CAN'T
write code to specifications.

The reason that they have these inabilities is that they have never
had to do any of these things in their programming courses. 

     What I would like to see in programming courses (freshman) is the
development of a project throughout the semester.  Not 3 or four
little independent programs (e.g. solving Tower of Hanoi, print "Hello
World" ...) but 3 or 4 programs that can be integrated to form a
larger program.  This would allow:

	1. Introduction to the language in small bytes. (weekly assignments)
	2. Examples of modularization (each project is a module)
	3. If you laid out specifications for each module then it would teach
	   the students how to write to specifications.
        4. Make the students estimate the number of hours they think
 	   it will take them.  Then have them note the amount of time
	   that it actually takes to get things working properly.

	5. For upper level courses make a larger project and have
 	   teams of people work on segments of each module.  E.G. in
	   data structures course one group designs a B-Tree ADT with
	   appropriate interfaces while another group tries to use the
	   unwritten B-Tree code for a cross-reference generator.
	   ( Just wait until the two teams get together and find out that
	   their code won't run because somebody didn't write their
	   code properly. This will give them a real taste of the
	   outside world :-).  (This method was used on me by the 
	   teacher of a Data Structures course that was offered as an
	   enrichment course, no credit, undergraduate teacher.)

	6. For senior level courses have the class work on a project
	   suitable for a master's thesis.  They need to do all of the
	   design specs, partition the problem to the various groups
	   and so on.

	a.   Benchmarking, Code control systems etc could be
	     introduced in 5 or 6.  Debuggers should be introduced
	     right in freshman year.  They are really useful time
	     saving tools.  Syntax directed editing should probabbly
	     be put off until after the students understand the syntax
	     of the language.  (Teach the multiplication tables then
	     give them calculators.)

Granted the set-up of this scheme would take a lot of time on the part
of the instructor, but I think it would better prepare the students
for the particular niche of life that they have chosen.

The nice part of this is that the 900 man-hours (30 people in 30
hrs/semester) is used to teach them more than just the theory of
whatever they are doing, it forces them to look at a larger picture
which they may not be able to understand but can still build.

Comments on the above via e-mail will be appreciated.  If you send me
flames get your mailbox asbestos lined.