Path: utzoo!attcan!uunet!cs.utexas.edu!uwm.edu!lll-winken!xanth!mcnc!duke!romeo!crm
From: crm@romeo.cs.duke.edu (Charlie Martin)
Newsgroups: comp.software-eng
Subject: Re: Theory vs. Practice in CS Education
Message-ID: <16185@duke.cs.duke.edu>
Date: 24 Nov 89 16:42:28 GMT
References: <15947@bloom-beacon.MIT.EDU> <4979@ae.sei.cmu.edu> <16169@duke.cs.duke.edu> <5072@ae.sei.cmu.edu>
Sender: news@duke.cs.duke.edu
Reply-To: crm@romeo.UUCP (Charlie Martin)
Organization: Duke University CS Dept.; Durham, NC
Lines: 182

In article <5072@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes:
>In article <16169@duke.cs.duke.edu> crm@romeo.UUCP (Charlie Martin) writes:
>
>>Richard, I don't mean this to be derogatory, but this really reads like
>>you haven't had much exposure to engineering in the field, or for that
>>matter to a working engineering organization that does much of anything
>>BESIDES software engineering.
>
>Let's try for a little closure here -- I am a registered professional
>engineer with 25 years of industrial design experience, with about 40% of it
>in software.
>

Fair enough: you've got 5 years on me, but 100% of my design experience
is in software (although I spent a lot of time with hardware people);
I've also -- to fend off the obvious question -- spent a lot of time
watching architects and engineers, and asking lots of questions, in
order to broaden my knowledge of the real processes involved.

Also, no PE (if there WERE a PE exam in software engineering, I'd take
it!) but a CDP and by next month sometime a PhD (ghods willing.)

>
>>While an architect is doing design, they should not be worrying about
>>the nail, screw, and rivet level.  They certainly do worry at the beam
>>level, because strength and cost optimizations determine things like
>>maximum clear span.
>
>The way they 'worry' about those things is to use model structures where
>they are certain that the detail designers can fill in the detail to create
>an instance of the model which meets the engineering specifications.  Agreed
>that in small firms or for small projects, the architect may fill more than
>one role, but that isn't the point.  The problem in software is that the
>roles of designer and implementer have not yet been distinuished.  We've got
>carpenters and bricklayers trying to design houses.  Every programmer is now
>a software engineer, but you won't find an architect in the field with a
>hammer.

I think we're beginning to converge on a point here.  One
counter-argument to point out is that in fact most architects work in
small firms, even though they design big buildings.  Even Frank Lloyd
Wright and Corboisier (sp? I think that's right) don't/didn't have
massive organizations.  What discussions I've had with architects and
what I've been able to glean from the design literature suggests that
architects are in fact conscious of the engineering problems of things
like maximum clear span, or rather increase of cost as clear span
increases optimized against client's goals, from the first moments of
design.  And a Wright or Corboisier may not be on site supervising 
construction, but a junior member of the firm is: the architect or his
firm is responsible for the nuts and bolts.

But you've got a major point here that I think needs serious
consideration: the designer is not yet separate from the carpenter in
software.  It's like the mechanical engineer being the machinist or
toolmaker.

The opposite side of this is that while mechanical engineers don't need
to be machinists, mechanical engineers need to understand machine tools
and manufacturing operations.  In some countries, this is done by
requiering engineering students to take a machine-work (construction
work, etc) course as part of the introduction.  When I was an
engineering student, we had to take a course that included projective
geometry, drafting, slide rule, and discussions of standard practices as
one requirement, a course in project management as another, and a course
on surveying as a third.  (This is all before software engineering was a
defined term.)  The purpose was to make sure that we understood
practical constraints and practices as well as ODEs and strength of
materials.

One reason SE doesn't make a distinction in teaching where ME does is
that there is little distinction in practice: most people hire a CS grad
to be a "software engineer" even though what they mean a new grad to do
is be a real SE's machinist.  The new grads aren't all that good as
"machinists" but they aren't well prepared to software engineer
either.  (Or worse, they hire a new grad to DO a software engineer's job
and think what they get is the best possible.)

The other side of this is that we can't TEACH software engineering
without requiring the students become machinists; there's not much you
can teach about programming without teaching programming.

The solution in my opinion is that we have to make sure that part of
teaching computer science is teaching the low-level skills that have
been considered part of software engineering up to now.  I don't think
any computer science grad ought to be able to graduate without
understanding how to write a good program at the 1000--10,000 SLOC
level.  It seems as silly to allow the contrary as it would be to give a
degree in English in which the recipient cannot write a competent
sentence, paragraph, or 5,000 word paper.  [Of course, that happens
too...]

>
>
>>It is true that most engineering disciplines use prebuilt components
>>when available, but not all.  Mechanical engineers will design special
>>components for fabrication, they just have the choice, something that
>>software engineers often don't (yet.)
>
>All of the components are created from known models, otherwise the engineer
>is doing science and not engineering.  We (in our project) are giving
>software engineers the choices, as we are helping to develop the
>design-level models.
>

Well, I can't respond to your research because I don't know enough about
it.  But when an engineer designs a bearing that is needed, which is not
in the parts catalogues from the acceptable suppliers, but which is
within the common state of art, he is not doing science: there is no
hypothesis/experiment cycle going on.  He just designs a left-handed
double-roller frammistan because he knows there are right handed ones,
but he can't find the left-handed one he needs to go on his new
left-handed power pipe wrench.

Similarly, all engineered software is created from known models (check
e.g. the plans work of Soloway) and most other algorithms are designed
on the basis of existing models as well.

In designing a bearing, a designer had better know about the properties
of other bearings, and of the materials that make them up.  He will
certainly hve seen a bearing in use, and will probably hav had
experience with various kinds of prefab bearings in various uses.  A
software designer needs to know the properties of his "materials" --
which means understanding something about architectures; needs to have
a background in the properties of his working stuff to know how to make
design choices -- which means a working knowledge of analysis of
algorithms, operating systems concepts, files systems, concurrency and
parallelism; and needs to have experience with other successful artifacts
which make use of the principles, and to have learned about them in the
context of the tradeoffs and optimizations that can be made.
>
>>I don't think anyone is under the impression that you are learning
>>engineering when learning about finite state automata and the executable
>>models of them.  
>
>This is true for you, but not for those who suggested (and still insist)
>here that courses in OS and compilers were good ways to learn software
>engineering.
>

I *am* glad that we have your infinite knowledge to draw on, Richard.
That is ever so much clearer now.  Funny, I had thought that the others
were mostly arguing that OS etc courses were a good place to *present
examples* of software engineering and its problems.  But being a mere
mortal, I can only draw on what I read, not on my intimate knowledge of
what other people know.

But as I recall the arguments presented (not just mine), the idea has
been all along that operating systems courses and compilers courses were
opportune places to expose students to large and complex programs.

There seem to me to be three tiers here:

	- the theory: analysis of algorithms; concurrency and parallelism; 
	  finite state automata, computability, NP-completeness; discrete
	  maths; discrete circuits; programming language semantics;
	  correctness and safety; queueing theory and Markov systems.

	- central concepts that apply to most or all computers: languages
	  and their differences; architecture (both in the Brooks sense of
	  opcode-set design and in the higher-level circuit sense);
	  constraints on resources and performce; organization of file
	  systems and file stores; tradeoffs and optimizations; important
	  algorithms uses in practice, like hierarchic chains of ordered
	  sets.

	- the backround needed to work in practice: code "hygiene";
	  commenting; modularization; concepts of reuse; maintenance and the
	  special skills that go with it; the idea of the life cycle and its
	  models (waterfall, spiral, etc); the idea of metrics.

I'm not wedded to the *names* of the courses; call them Larry Moe and
Curly for all that I care.  But many of the theory topics presented must
(in my opinion) be reinforced with realistic examples, and courses like
compilers, operating systems, and oh, data base courses are a convenient
place to do this.  Contrariwise, it appears to me that once one has seen
the theory topics above, and seen them in practical applications for
reinforcement, that one has studied the content of the "objectionable"
courses no matter what they are called.

So I don't know -- what doesn't the list include?  What do you think is
*not* appropriate for a software engineer to know?
Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm)