Path: utzoo!utgpu!water!watmath!clyde!att-cb!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!umd5!umbc3!tron!carson
From: carson@tron.UUCP (Dana Carson)
Newsgroups: comp.software-eng
Subject: Re: Cynic's Guide to Software Engineering, part 4
Summary: disagree on order of work
Keywords: Software Engineering Education
Message-ID: <252@tron.UUCP>
Date: 15 Apr 88 23:52:54 GMT
References: <2677@Shasta.STANFORD.EDU>
Distribution: na
Organization: Westinghouse D&EC, Baltimore, MD
Lines: 40

In article <2677@Shasta.STANFORD.EDU>, neff@Shasta.STANFORD.EDU (Randy Neff) writes:
> programming jobs.  (Can you believe that at some schools, individuals are 
> teaching how to program that have never been outside of academia or written
> a program used by other folks!)  Ask your Software Engineering Education
> expert: "How many lines of delivered code did you personally write last year?"

Unfortunitly true in most fields.  Shouldn't be encourged though.

> The key focus of a Masters program of software engineering should be an 
> apprenticeship working on a real, large software project, in all phases of
> the lifecycle myth.  I suggest that a complete software engineering programming
> environment be the continuous project for all of the students over the years.   
> It would be designed to be portable, run on several different hardware /os 
> platforms and would be given away to anyone asking.  It would go with every
> graduating student.  It would be treated just like a real software product from
> a real company, including support, new releases, bug fixes, manuals, training.
> The system would start out small, say just the database/configuration/version
> management; then be expanded with syntax directed editors, graphic editors,
> regression testing, reuse libraries, application generators, whatever the 
> current fad happens to be.
> Students would enter the school at the support end, working on maintenance;
> then move into minor enhancements, then major ones;  finally, as a team 
> propose, specify, design, construct, integrate and test a new or replacement
> subsystem.  

NO.  There is too much feeling that maintence is where you stick the
new/incompatent people already.  Start with write the fully defined
routine.  Write this small set of routines, design a small subsystem,
etc.  Then when they show that they know how a subsystem works risk
letting them work on it.

Also teach maintence.  How to restructure code, deduce algorithms from
uncommented source, check for globals that cause unexpected linkages,
old language standards etc.

--

Dana Carson
Westinghouse
uunet!umbc3!tron!carson