Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!brl-adm!seismo!ut-sally!cs!utah-gr!uplherc!esunix!loosemor
From: loosemor@esunix.UUCP
Newsgroups: comp.edu
Subject: Re: Software Engineering vs. Computer Science
Message-ID: <36@esunix.UUCP>
Date: Tue, 31-Mar-87 11:36:23 EST
Article-I.D.: esunix.36
Posted: Tue Mar 31 11:36:23 1987
Date-Received: Sat, 4-Apr-87 10:18:18 EST
References: <193@darth.UUCP>, <4422@utah-cs.UUCP>
Lines: 44

One difference between undergraduate Computer Science courses and
undergraduate courses in other engineering fields is that CS courses tend to
emphasize design problems more than analysis problems.

I can honestly say that I got through an undergraduate mechanical engineering
program and an MS program in engineering mechanics without having to design a
single mechanism or structure for any of my classes.  (Admittedly, my 
specialty was solid mechanics rather than design, but the design elective 
sequence was essentially a 3-quarter senior project course.)  Our labs mostly 
concentrated on how to design a good test setup so you could get the data you 
needed to do the analysis on your mechanism or structure.  Mechanical design 
is largely a trial-and-error procedure:  you build a prototype (either 
physically or now, a computer model); you analyze it to find its weaknesses; 
you tweak things a little, analyze some more; increase the level of detail on
your model, analyze some more; and so on until you end up with something that 
meets your requirements.

Now that I have switched to being a Computer Scientist, I find that the
biggest software engineering problems result from the common misconception
that the initial design of a large piece of software should also end up
being the final product.  Undergraduate CS courses do not teach students
the value of analyzing and improving their programs:  you hand them in and
you're done.  Too often, I've seen software design in the real world done 
by producing massive specifications of every detail of the system before 
even beginning to code, followed by a last-ditch effort to get the code 
completed on time (some major problem that was unanticipated in the spec 
invariably crops up during the implementation).  As a result, the code is
often poorly written, hard to maintain, and final product sometimes doesn't
even meet the initial design goals because some detail was overlooked in
the spec and nobody realized it was missing until the system was up and
running.  The value of prototyping and testing crucial parts of the system 
before commiting to them in the specification seems very foreign to computer 
types.  

I find that when I build programs, I start out with something fairly crude
and often rework parts 3 or 4 times before I'm satisfied with them.
Sometimes I discard the previous code completely and start over again:  it's
not wasted if I've gained a deeper understanding of the problem domain from
it, or if my new code is significantly cleaner and easier to maintain.  My
experience has been that this approach is almost universal among engineers
who have been trained in other fields before becoming programmers.

-Sandra Loosemore
{decwrl, utah-gr!uplherc}!esunix!loosemor