gary@darth.UUCP (03/27/87)
I am a recent subscriber to comp.edu, but have read many articles in which
the terms Software Engineering and Computer Science are used almost inter-
changably.
There seems, in general, to be a lack of understanding of what Software
Engineering actually is. If you've written a game for an Atari, are you
a Software Engineer? If you've written an rule-based simulation for a
Symbolics, are you a Software Engineer?
There are three separate issues at hand when we talk about the creation
and understanding of Software:
1. Programming. I view this as the simple ability to understand
and produce logical sequences of imperatives which tell a
computer what to do. There are programmers in the fifth
grade, but probably few software engineers.
2. Computer Science. Computer Science attempts to understand and
define the process of computing. Its tools are observation and
experimental investigation.
3. Software Engineering. This is the process of applying the
principles of automation to practical ends. The goal is to
produce efficient and economical systems using technology
which is both reliable and predictable.
Are educators working to produce curricula which focus on CS and SE as
distinct areas of study? Very few of my co-workers have an understanding
of Software Engineering which was not gained from experience. In fact,
to become good engineers, many people must unlearn principles taught to
them in CS courses. Producing large, complex software systems is a different
kind of problem than writing a 300 line program. Data abstraction is an
interesting twist in a small program, but essential in a large system.
My point of all of this is focus. Students who wish to unravel the secrets
of computing (and probably the mind as well) are rarely satisfied with the
engineering of software. Those interested in practical solutions to real
problems are rarely interested in the science of computing. Many software
people lack an understanding of this simple duality.
Comments and flames are welcome on these issues. Are these problems
being solved? Are they solved already and am I not-so-blissfully
ignorant?
Gary Wisniewski
uucp: {allegra,bellcore,cadre}!pitt!darth!garyshebs@utah-cs.UUCP (03/28/87)
In article <193@darth.UUCP> gary@darth.UUCP (Gary Wisniewski) writes: >There seems, in general, to be a lack of understanding of what Software >Engineering actually is. If you've written a game for an Atari, are you >a Software Engineer? If you've written an rule-based simulation for a >Symbolics, are you a Software Engineer? Well, what's the answer? *I* sure don't know! The typical definitions for SE seem to focus more on the process than the result, so you can get well-engineered games and hacked-out simulators... >Are educators working to produce curricula which focus on CS and SE as >distinct areas of study? Very few of my co-workers have an understanding >of Software Engineering which was not gained from experience. In fact, >to become good engineers, many people must unlearn principles taught to >them in CS courses. Producing large, complex software systems is a different >kind of problem than writing a 300 line program. Data abstraction is an >interesting twist in a small program, but essential in a large system. This is exactly the kind of attitude I was decrying in an earlier article. Students have to be able to build little things before they can build big things. This is true of any engineering field. EE's build circuits with one resistor and one capacitor, then one transistor, then one IC. They don't even think about VLSI or continental power networks until fairly late in their student career, and will not generally *build* sizeable things until grad school. The same is true of other engineering disciplines. Let's not start flagellating ourselves because students don't write 10K+ line programs as undergraduates! The remark about "not understanding SE without experience" touches on an old bone of contention between academia and industry. Just last week I noticed a letter in an IEEE rag, stating that academia did not prepare students adequately for work, and proposing (among other things) that tenure be abolished, and that university faculty should consist of one-half industry people. No mention was made of how those people were going to be coerced into teaching... I believe that it's *never* going to be the case that universities will prepare students for industry to industry's specifications. That's just not the way the world works. >My point of all of this is focus. Students who wish to unravel the secrets >of computing (and probably the mind as well) are rarely satisfied with the >engineering of software. Those interested in practical solutions to real >problems are rarely interested in the science of computing. Many software >people lack an understanding of this simple duality. CS hasn't been around long enough to develop standards on how much theory the engineering types should know, or how competent a theoretician ought to be in the practice of programming. Presumably you don't want ignorant software engineers to spend a lot of time and effort trying to write a "program to detect all infinite loops in other programs"! If you divided up theory and practice now, the theory would spin off into the ozone (a la Soviet computer science), and the practice would drift into the reinvention of exponential algorithms for sorting. I personally prefer to be able to do both theory and practice. I suppose many people in CS departments like that too, which is maybe why there hasn't been much impetus for splitting departments (can you imagine physicists and EEs and MEs bundled into the same department? It would last one week, or until a seminar, whichever came first...) >Gary Wisniewski >uucp: {allegra,bellcore,cadre}!pitt!darth!gary stan shebs shebs@cs.utah.edu (I've been in both industry and academia and am now considered too theoretical for industry and too practical for academia. What a bind! :-) )
anson@elrond.UUCP (03/30/87)
In article <4422@utah-cs.UUCP> shebs@utah-cs.UUCP (Stanley Shebs) writes: > >(I've been in both industry and academia and am now considered too theoretical >for industry and too practical for academia. What a bind! :-) ) That can work both ways. In academia, my students were happy that I could provide some practical perspectives. Now, in industry, my theoretical background helps me to solve some of the tougher problems. When I was just finishing grad school (1975), Software Engineering was just becoming a topic in Computer Science. It was highly theoretical, because nobody knew how to treat it as a discipline yet. A lot of progress has been made, but I still think of SE as application of specialized theory. But that's *my* problem. :-) -- ===================================================================== Ed Anson, Calcomp Display Products Division, Hudson NH 03051 (603) 885-8712, UUCP: [decvax, wanginst, savax]!elrond!anson (Just blame me; my boss isn't even certain about just what I do.)
loosemor@esunix.UUCP (03/31/87)
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