Xref: utzoo comp.edu:2607 comp.software-eng:2318
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rice!uw-beaver!Teknowledge.COM!unix!hplabs!hp-sdd!ncr-sd!ncrcae!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
Newsgroups: comp.edu,comp.software-eng
Subject: Re: CS education
Message-ID: <6995@hubcap.clemson.edu>
Date: 9 Nov 89 18:55:14 GMT
References: <34705@regenmeister.uucp>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 159

From wtwolfe@hubcap.clemson.edu (me):
>   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.

From Neal Murphy:
> [argues relevance of OS/architecture to systems programming]

 I do not disagree that writing an OS and/or studying architecture
 might be useful to systems programmers; however, we must recognize
 that, as pointed out by the ACM Task Force on the Core of Computer
 Science, "Many computing graduates wind up in business data processing,
 a domain in which most computing curricula do not seek to develop
 competence." (CACM, Jan '89, p. 13).  Such graduates have no use
 for systems programming expertise, and a significant percentage of
 them are likely to be actively disinterested in working at that low
 a level.  What the OS/architecture requirements are asserting is that
 these students should be compelled to take such courses anyway, which
 in my view is ridiculous.  

> Besides, writing an operating system allows one to use, at least once,
> most of what he learned from the CS program: human factors, scheduling
> theory, queuing theory, compiler theory, networking. In addition,
> the typically quiet, introverted gweep learns how to work in a team,
> and learns that no one person can do everything.

  Amazingly enough, software engineering courses are precisely the
  courses in which the rest of the CS program is put to work within
  a classwide project (as opposed to two-or-three-person teams, which
  is still small enough to avoid effectively demonstrating the issues
  pertaining to programming-in-the-large...); rather than attempting
  to provide such things as an incidental side effect of a course which
  is really about an obscure domain, why not increase the coverage of
  software engineering so that these things will be achieved as a 
  *primary* objective?
 
> The disadvantage of your idea is that students would be encouraged to
> become specialists 

  Quite the contrary, I propose that the increased study of software
  engineering be done in order to AVOID overspecialization (e.g., into
  obscure areas like architecture and operating systems, in which very
  few people are full-time workers these days).  A solid background in
  software engineering prepares one to go out and construct high-quality
  software in general, regardless of the specific application area.

From Peter Damron:
> I believe that operating systems and architecutre are two subjects
> that undergraduates should learn something about.  The projects may or
> may not be very applicable to their education, but almost any project
> is likely to teach something about software engineering.

  But notice that what I proposed instead was precisely an increase 
  in the coverage of software engineering!!  

> I would submit that there is not much more than a quarter or semester
> worth of material about software engineering that is not taught in some
> other CS class.

  I would submit that this is (I will try to phrase this delicately)
  grossly incorrect; if there is any truth to this statement, it is
  precisely because the amount of software engineering material which
  is presently being taught is artificially low due to the diversion
  of teaching resources into the teaching of highly specialized and
  largely irrelevant material to many people who would rather be 
  learning more relevant things about software engineering instead. 

From Ian Kluft:
> [thinks there should be courses which will "wash out" underachievers]

   At my undergraduate institution, Purdue University, the big
   "wash-out" course was Algorithm Design and Analysis, using
   the Horowitz and Sahni textbook; the nice thing about it was
   that this material is extremely relevant to computer science
   practitioners (dynamic programming, branch-and-bound, greedy
   algorithms, NP-completeness, and so on), so the students could
   hardly claim that they were unjustly eliminated.

   Incidentally, there was also a course in the Information Systems
   route of specialization called Systems Programming, which was 1/2 
   operating systems and 1/2 compilers; I think this is an excellent 
   start, which should be extended to include surveys of assembly 
   language, computer architecture, and microprogramming, thereby
   clearing up 9 more semester hours for the increased study of 
   software engineering and other more relevant topics.    

From Dan Pick:
> 1) Is knowledge priceless?

   No, it has a cost; just ask every tuition-paying student.  

> operating systems are an active field
> of research in which a faculty member may pass on something of
> the flavor of researching a body of knowledge, while at the same time 
> teaching his or her students how to design a new system.

   True, but I'm arguing that this flavor should be passed along
   within a context of relevant and interesting material; the way
   to ensure this within the context of operating systems courses
   is to see to it that the people who are there took the course
   because of an interest in the material rather than simply an
   interest in eventual graduation. 

From Dick Dunn:
% In the traditional nomenclature, the terms "science" and "engineering" are
% used in naming disciplines which are relatively "pure" vs "applied".  That
% is, engineering disciplines are for applying the principles developed in
% the corresponding sciences.
% 
% This creates a serious problem for "Computer Science":  For the most part
% there IS no corresponding engineering discipline, so people expect the
% Computer Science departments to provide the "applied science" education as
% well.  Software engineering is beginning to make some inroads here, but
% (a) it's on the borderline of qualifying as "engineering" in the
% traditional sense and (b) it's only one narrow area of where "engineering"
% is needed to correspond to computer science.  [...]
%
% The greater problem is the dissonance between what many universities think
% Computer Science should be and what industry thinks it should be.  [...]
% We're training people as computer scientists when that's not what they 
% need or want...but it's as close as they can get to their real interests.

   Dick is exactly right; this gets back to the letter in September's
   CACM, "Information Systems is an Engineering Discipline".  But until
   such time as software engineering gets its own department, perhaps
   within the school of engineering (vs. science), CS departments need to 
   recognize the need to accomodate future engineers as well.

From Chris Prael:
% There is a basic set of disciplines to engineering.  This set seems to
% be well taught in civil and mechanical engineering curricula and less
% well in electronic engineering curricula.  The set seems to be taught
% little or not at all in the typical computer science curriculum.
% 
% In my experience, people with CS degrees generally, but not universally,
% come out of college trained to function as technicians rather than as
% engineers.  Technicians have lots of techniques but not much discipline.
% They cut and try a lot (formally known as prototyping) and generally put
% together something that just about works.
% 
% An engineer is trained to organize and solve a problem in his head.  The
% ordinary ones simply apply the conventional sollutions with pedestrian
% but reliable results.  The great engineers devise sollutions that are
% works of art.

   Well said.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu