Xref: utzoo comp.edu:2601 comp.software-eng:2307
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!mcnc!duke!romeo!crm
From: crm@romeo.cs.duke.edu (Charlie Martin)
Newsgroups: comp.edu,comp.software-eng
Subject: Re: CS education
Message-ID: <16028@duke.cs.duke.edu>
Date: 9 Nov 89 03:20:47 GMT
References: <11064@cbnews.ATT.COM> <6961@hubcap.clemson.edu>
Sender: news@duke.cs.duke.edu
Reply-To: crm@romeo.UUCP (Charlie Martin)
Organization: Duke University CS Dept.; Durham, NC
Lines: 77

In article <6961@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From kww@cbnews.ATT.COM (Kevin W. Wall):
>> Just once I'd
>> like to see a homework assignment in some CS course be something like
>> 
>> 	"add features X and Y to this 60,000 software system (which the
>> 	students have never seen before) and turn it in next week".
>
>   course here at Clemson University; last semester, we gave students a
>   large prewritten software system and had them implement several changes
>   to it as part of their semester project.  It *does* happen. 
>
	See also "Adding Reviews, Prototyping, and Frequent Deliveries to
	Software Engineering Projects," Connie U Smith and Charles R.
	Martin, _Issues in Software Engineering Education_, Fairley and
	Freeman, eds. Springer Verlag 1989.

	It *does* happen, no kidding.  But it appears to be rather rare.  It
	means that someone has to make an effort preparing the assignments,
	and it helps if the people doing the assignments and the grading
	have actually done some maintenance themselves.

>   In general, I agree.  In practically every CS program, students
>   spend lots of time writing operating systems, etc; this is fine
>   if a student wants to specialize in this area, but it should not
>   be required of those who do not.  There is far too much software
>   engineering material, material which would be of great practical 
>   benefit REGARDLESS of application area, which there is not presently
>   enough time to teach.  Why?  Because they are off studying operating
>   systems (as if more than 1% of them would ever make use of the material),
>   architecture (shouldn't this be left to the computer engineering program?),
>   and so on.  Again, I have nothing against this material for those who
>   are interested, but I have major disagreements with the proposition that
>   such material from what today is a fairly remote area of specialization 
>   should be required of ALL students taking a CS program.

I think you're completely off the wall here, especially when you're
talking about education at the master's degree level or higher.  I agree
that there is a fairly large area of software engineerin material that
would be very useful, and more being discovered/invented every year:
there is a fair bit of real science and good engineering that is
involved with problems of configuration control, correctness,
specification, etc.  There is also a lot of stuff that software
engineering is sort of stuck with but ought to be part of simple
programming literacy, like cleanly realized code, testing plans and
schemes, reviews or walkthroughs, etc.  In my opinion, it ought not be
possible to graduate with a degree in Computer Science without
deminstrated ability to write programs, any more than one can have a
degree in English Literature without a demonstrated ability to read and
write English, or a degree in medicine without knowing anatomy.

There is also a lot of software engineering that has little or nothing
whatsoever to do with computer science, and which I think belongs in a
business school: things like life-cycle models, management metrics, etc.
These are NOT the things which computer science or even traditional
engineering deals with; they are much more like the quantitative methods
that an MBA uses.

But HOWEVER: the grounding in things like operating systems, at least in
the ways I have seen them taught even at an excessively theory-oriented
school at Duke, are ESSENTIAL for the practicing, competent software
engineer.  Even if you don't write an operating system yourself, there
are problems in real-time programming that are essentially operating
systems problems, and bugs in real-time programs that have to do with
the precise operation of the operating system itself, e.g. the
scheduler.  The techniques that come from learning to write compilers
also are useful to solve a large variety of real-world problems even if
you can't spend your time writing compilers.  And I think the
mathematical sophistication that comes from learning computability
theory is central to learning, REALLY learning, how to consider
correctness in a program, of which software engineering has no which-er.

I'm saying this as a person who came to grad school as an experienced
software engineer and a firm believer in just the position that Bill
Wolfe proposes.  I was wrong then.  I think Bill is wrong now.

Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)