[comp.edu] software engineering

ncmagel@ndsuvax.UUCP (03/21/87)

     At what level should students be taught software engineering principles and
concerns?  How much should be covered in the introductory courses, how much
should be presented to non-majors?  Should the material be a part of courses 
whose emphasis is another topic (e.g., data structures, operating systems),
or should there be specific courses which concentrate on design, on testing, etc.
?
     When and how often should students do project assignments?

tlh@arthur.cs.purdue.edu.UUCP (03/22/87)

In article <340@ndsuvax.UUCP>, ncmagel@ndsuvax.UUCP (ken magel) writes:
> 
>      At what level should students be taught software engineering principles and
> concerns?  How much should be covered in the introductory courses, how much
> should be presented to non-majors?  Should the material be a part of courses 
> whose emphasis is another topic (e.g., data structures, operating systems),
> or should there be specific courses which concentrate on design, on testing, etc.
> ?
>      When and how often should students do project assignments?

    The questions you ask have no absolute answers.  Like economists, if you
    take n CS people to decide such issues as you mentioned, you may
    come up with n+1 or more opinions.
    
    My (limited) experience has been that software engineering principles
    should be taught (obviously). But the extent of that instruction
    depends on faculty resources, and how the faculty have "designed" the
    major (and many other things as well).

    Regarding intro courses for non-majors, there seems to be a trend to
    focus on investigating sociological issues of computing rather than 
    learning to program in (gads) BASIC.

    Personally, I feel that large "Senior" projects provide students with
    adequate software engineering principles to go out and be successful.

    In addition to reading the journals for the experts' opinions on such
    matters, the Univ of Minn, Morris is modifying their curriculum and 
    you may like to contact them and compare notes.  (They are close to NDSU
    and although small they are working hard to develop a good CS major.)

    Tom
-------------------------------------------------------------------------------
Thomas L. Hausmann           |   
Graduate Assistant           |   tlh@mordred.cs.purdue.edu    ( ARPA )
Dept of Computer Science     |
Purdue University            |   ...!purdue!tlh   ( UUCP  )
-------------------------------------------------------------------------------

burgess@izar.UUCP (03/22/87)

In article <340@ndsuvax.UUCP> ncmagel@ndsuvax.UUCP (ken magel) writes:
>
>     At what level should students be taught software engineering principles and
>concerns?

As early as possible.  If they take the shot gun approach (well, maybe THIS
line has the bug in it) it takes forever to break them of it.  Also, if you
give them a good step-by-step method to write programs, they might use it.

>           How much should be covered in the introductory courses, how much
>should be presented to non-majors?  Should the material be a part of courses 
>whose emphasis is another topic (e.g., data structures, operating systems),
>or should there be specific courses which concentrate on design, on testing, etc.
>?

Again, hammer it into their little heads from the very beginning and do the 
same with non-majors.  I speak from experience here, I've taught the intro
FORTRAN course to engineers and I teach the second computer course to the 
ones who survive the first.  I found that the people I taught (who had the
principle hammered into them) handle the second course much better, besides
being able to write pretty decent code.  The people from other classes
frequently can't write a simple DO loop and are hopelessly lost when they have
to write a 150 line program.

I think it is important to realize that a lot of the code used by the scientific
community is written by engineers, and they often don't understand software
design.  If they were taught the same principles, there would be a lot of time, 
$$$$ and effort saved in the industry.

>     When and how often should students do project assignments?

I think that programming classes should be worth more credits so that the
students can be required to do larger and longer projects.  I think they should
have written a 300 line program by the end of the first class.  (this may
already be true in the CS classes, but engineers only write ~100 line programs
by the end of class).

I'm afraid that I froth at the mouth when I discuss how little students know
about programming, sorry this is so long.

rebecca

djm408@tijc02.UUCP (03/24/87)

in article <340@ndsuvax.UUCP>, ncmagel@ndsuvax.UUCP (ken magel) says:
> 
> 
>      At what level should students be taught software engineering principles and
> concerns?  How much should be covered in the introductory courses, how much
> should be presented to non-majors?  Should the material be a part of courses 
> whose emphasis is another topic (e.g., data structures, operating systems),
> or should there be specific courses which concentrate on design, on testing, etc.
> ?
>      When and how often should students do project assignments?

     It is my belief that computing has matured to the point that Software
Engineering should be split off from Computer Science as separate a discipline.
This is analogous to the split between chemistry and chemical engineering.

     Software engineering students should be taught engineering concepts from
the beginning, including design, analysis, and project management. This does
not mean that they shouldn't be taught some theory. Just as a chemical
engineer needs a solid foundation in chemistry, a software engineer needs
a solid foundation in computer science, including data structures, ai
concepts, basic computability and automata theory, etc. However, the
software engineering student should concentrate on applications of theory
rather than the theory itself.

     On the other hand computer science students should be taught a curriculum
heavily oriented towards the theoretical: data structure analysis, computabilityand automata theory, graph theory, topology, etc. However, they should have
a good foundation in programming, just as good chemists need to know
laboratory procedures; after all, theories need to be tested.

     Unfortunately, many CS departments teach an amalgam of the two types of
curricula, leaving the student with a less than solid foundation in either.

wfi@rti-sel.UUCP (03/25/87)

In article <141@tijc02.UUCP> djm408@tijc02.UUCP (David Marks         ) writes:

>     It is my belief that computing has matured to the point that Software
>Engineering should be split off from Computer Science as separate a discipline.
>This is analogous to the split between chemistry and chemical engineering.

Bravo! I couldn't agree more. In fact, I think the split is LONG
OVERDUE. There are, I think, a few programs in software engineering 
around. For example, there's the Wang Institute for Graduate Studies 
in Tyngsboro, Mass. that offers a Master's degree in software 
engineering. Anyone know of any other S.E. programs?

                                  -- Bill Ingogly

ramesh@cvl.UUCP (03/26/87)

In article <141@tijc02.UUCP> djm408@tijc02.UUCP (David Marks         ) writes:

>     It is my belief that computing has matured to the point that Software
>Engineering should be split off from Computer Science as separate a discipline.
>This is analogous to the split between chemistry and chemical engineering.

I concur entirely with David's remark. The preperation needed for
Software Engineering and CS are completely different. A lot of
good can be got by offering different courses and degrees for both.
The present day graduates know very little of either. Specifically,
people interested in theoretical work gain very little mathematical
maturity in their courses as is required to do research in these areas.

				Ramesh Sitaraman
-- 
-------------------------------------------------------------------
ARPA: ramesh@cvl.umd.edu                  | The only thing we have to fear
PH: (301) 454 5858 (off)                  | on this planet is man.
    (301) 927 6831 (home)                 | Carl Jung, 1875 -1961

del@homxc.UUCP (03/26/87)

In article <623@charon.UUCP>, burgess@izar.unm.edu (Rebecca Burgess) writes:
> In article <340@ndsuvax.UUCP> ncmagel@ndsuvax.UUCP (ken magel) writes:
> >
> >     At what level should students be taught software engineering principles and
> >concerns?
> 
> As early as possible.  If they take the shot gun approach (well, maybe THIS
> line has the bug in it) it takes forever to break them of it.  Also, if you
> give them a good step-by-step method to write programs, they might use it.
> 
There is a difference between software engineering and software
design. (Duck, personal opinion coming) Software engineering is used
for programs that are over 10000 lines. Why bother with a lot of
measures and management on smaller projects?

Furthermore, you can't teach software engineering to those who haven't
experienced the problems that are unique to large projects.

On the other hand, make their brains sweat with the software design!
Its never to early to teach good programming. The more often the
better. Like writing, it's practice that makes good writers. (Great programmers
are still "born" however). It doesn't hurt to expose them to the
literature of the greats, either.

David Leasure
ihnp4!homxc!del

shebs@utah-cs.UUCP (03/26/87)

In article <1285@rti-sel.UUCP> wfi@rti-sel.UUCP (William Ingogly) writes:
>In article <141@tijc02.UUCP> djm408@tijc02.UUCP (David Marks         ) writes:
>
>>     It is my belief that computing has matured to the point that Software
>>Engineering should be split off from Computer Science as separate a discipline.
>>This is analogous to the split between chemistry and chemical engineering.
>
>Bravo! I couldn't agree more. In fact, I think the split is LONG
>OVERDUE. There are, I think, a few programs in software engineering 
>around. For example, there's the Wang Institute for Graduate Studies 
>in Tyngsboro, Mass. that offers a Master's degree in software 
>engineering. Anyone know of any other S.E. programs?
>
>                                  -- Bill Ingogly

I doubt anybody disagrees that there is a distinction, and that students
can follow either path, but there are some practical difficulties with the
split.

Most CS departments would have to be cut into two pieces.  There are only a
handful sufficiently large to withstand such a division.  What would happen
to a pure CS department of two, or an SE department of four?  They would
not be created in the first place, and the faculty either sent packing (bad
policy) or left in the new department (very uncomfortable).  Ultimately the
consequence is a CS department hopelessly isolated from their source of
things to think about, or an SE department out of touch with the latest
research.

Somebody else mentioned that "software design" should be taught instead of
"software engineering".  "Software engineering" has unfortunately become
associated with management of large program development, and that's one of
the weaknesses of the specialized SE degrees.  People come out of them
declaiming about how software *should* be done, but can't necessarily 
program their way out of a paper bag.  (If the MSE degree is so great, why
haven't they been producing ten times as much software as the unenlightened?
Surely MSE software should have taken the computer world by storm already!)
Mechanical engineers start by studying and building simple mechanisms long
before learning about space shuttle project management.  Interestingly,
design of mechanisms in ME is considered semi-magical, and only a few people
(mechackers?) really have a talent for it...

So here are my two impractical proposals:

1. Broaden the meaning of "software engineering" to be any part of applied
computer science.  This would cut across areas like graphics, operating
systems, AI, languages, and so on.  At the same time, recognize that some
people's work will not be easily classified into each category.

2. The largest departments should try a split on an experimental basis.
Each faculty member would have to decide which way to go.  Equipment and
maybe space should be shared at first, perhaps splitting up later.

							stan shebs
							shebs@cs.utah.edu

(Now that I've made the suggestions, it seems that the first is culturally
improbable, while the second is politically impossible.  But stranger things
have happened - computer science at Texas A&M used to be part of the
industrial engineering dept!)

cwruacm@cwruecmp.UUCP (03/26/87)

In article <340@ndsuvax.UUCP> ncmagel@ndsuvax.UUCP (ken magel) writes:
>
>At what level should students be taught software engineering principles
>and concerns?  How much should be covered in the introductory courses, 
>how much should be presented to non-majors?  Should the material be a 
>part of courses whose emphasis is another topic (e.g., data structures,
>operating systems), or should there be specific courses which concentrate
> on design, on testing, etc.?

Here at CWRU, seniors in Computer Engineering must take a course during the 
Fall Semester called "Design Methodology".  It covers (depending on the 
professor -- there are different professors for the course every year) the
software life cycle in some depth, with more or less equal emphasis being
placed on each phase of that life cycle.  This is the course that explicitly
covers this subject area, though >>slight<< emphasis is given in other 
courses.  Very little of the principles of software engineering is covered
in classes that may contain students whose major is not Comp. E. (in my
experience).

I believe that this is the proper time for such a course that covers the
subject in depth, but that more emphasis on principles such as good
specification and how it leads to good design, and the importance of testing
should be covered in lower-level courses such as a data structures course
where students receive their first experience writing "non-trivial" programs.

In my own experience as an undergrad here, I found that little emphasis was
given at lower-level courses like data structures and systems programming.
I used to sit down at a keyboard the day before my data structures assignments
were due (this was two years ago -- I don't do this anymore) with no design,
no plan of attack, and just "hack" until I got something that worked for the
examples that we were given to run.  Systems Programming was a little better,
but there was no explicit emphasis on any of the real principles of software
engineering.  It was not until the second semester of my Junior year that I
took a course that even discussed testing methodologies.  This has led me to
conclude that teaching some principles of Soft. E. would make the undergrad
courses a little less "painful" and help the move away from "here is the 
assignment statement (the requirements), here are some examples to run to
show the grader that your program works, now come back in two weeks with a
program".  This sort of inspires an "ad hoc method" of design that doesn't
always work.

I'm not advocating the teaching of specific design methods like JSD or VDM
to sophomores, just exposure to some principles that may ease their way 
through the sequence of core courses.


>     When and how often should students do project assignments?

Our Design Methodology course had one assignment, a term project.  We followed
the life cycle very closely, handing in requirements, specification, and design
documents, then (and only then) writing the code, and turning in a final 
summary report that included our testing methodology.

I hope that this article inspires some discussion of the various methods used
in Universities around the world.


Chet Ramey

ARPANET:  cwruacm%case@relay.cs.net
	  ramey%cwru-20%case@relay.cs.net
CSNET:    cwruacm@case  or  ramey%cwru-20@case
UUCP:     {...}!decvax!cwruecmp!cwruacm
	  {...}!decvax!cwruecmp!ramey@cwru-20  (depending on your mailer)
BITNET:   ramey%cwru20@cu20b

"Now, that wasn't much of a noise, was it?  Don't everybody try to play it
TOO safe!"
						The Art of Noise

ardis@wanginst.UUCP (03/27/87)

In article <1285@rti-sel.UUCP> wfi@rti-sel.UUCP (William Ingogly) writes:
>... There are, I think, a few programs in software engineering 
>around. For example, there's the Wang Institute for Graduate Studies 
>in Tyngsboro, Mass. that offers a Master's degree in software 
>engineering. Anyone know of any other S.E. programs?

Unfortunately, Wang Institute is going out of business.  Dr. Wang has
decided that he cannot support it any longer.  While our future is
still uncertain, it is very unlikely that the MSE program can be saved
as-is.

There are other MSE-like programs:  Seattle University offers an
MSE degree, and Texas Christian offers a similar degree.  Dartmouth
has a Computer and Information Systems program that includes much of
the same material.  Other schools offer programs in computer science
or business that stress software engineering.

-- 
Mark A. Ardis                           ardis%wanginst@CSNet-Relay (CSNet)
Wang Institute of Graduate Studies      ...!decvax!wanginst!ardis (UUCP)
72 Tyng Road, Tyngsboro, MA 01879-2099  (617) 649-9731

spf@clyde.UUCP (03/27/87)

In article <4414@utah-cs.UUCP> shebs@utah-cs.UUCP (Stanley Shebs) writes:
>In article <1285@rti-sel.UUCP> wfi@rti-sel.UUCP (William Ingogly) writes:
>>In article <141@tijc02.UUCP> djm408@tijc02.UUCP (David Marks         ) writes:
>>>     It is my belief that computing has matured to the point that Software
>>>Engineering should be split off from Computer Science as separate a discipline.
>>>This is analogous to the split between chemistry and chemical engineering.
>I doubt anybody disagrees that there is a distinction, and that students
>can follow either path, but there are some practical difficulties with the
>split.

I write:

Before I start, let me say that one of my degrees is in Computer Science.
Now, that behind me, I've come to believe that there is no such thing.

You see, though I know there are more liberal definitions, I believe
that science is the study of what IS by application of the scientific
method (which I will not belabor, but which is intrinsically
empirical and NOT inventional).  I've studied some science.
My undergrad and early grad work were in physics, where we studied
the properties of the Universe with the tools of observation and logic
(the latter usually using the language called mathematics).
Since my "Computer Science" MS, I undertook graduate work in
psychology, especially psychophysics (also a misnomer, I suppose).
Psychology is today where physics was in Newton's time, so in addition
to being exciting and dynamic, it provides insight into the process
of "doing science".  Again, we study what IS by observation and logic.

Now, I'm led to reconsider what "computer scientists" do.  Do they
"discover" algorithms that are floating in Plato's Ideal realm?
Then they are like mathematicians who "discover" new algebras.
And maybe this is what some folks mean by science.  But I believe
(as I've already hinted) that mathematics is a language, and not
a science, mostly because I don't think its entities occupy space
in Plato's ideal realm (or anyone else's, for that matter).  This
is not intended to denegrate mathematics; I simply mean to put
it in perspective.

I think that without TOO much handwaving I could make a convincing
argument that most (if not all) of what "computer scientists" do
(even those researchy folks) can be reduced to algorithms (yes, even
language theory, though that leans heavily on abstract algebra too).

So, my claim is that there is no computer "science" -- there is
computer engineering, some research and some applied.

To extend the analogy put forward (above) by David Marks, I think this
is just like Chemical Engineering -- which includes both research
endeavors as well as design.  In fact, in my previous position at
Exxon, MANY of the researchers in Corporate Research were "Chemical
Engineers" investigating chemical processes; this seems much like folks
at Bell Labs area 11 investigating computing processes.  And it
was (and is) different than the "Chemists" studying chemical
principles.

Maybe my argument doesn't matter; I've still identified "research"
and "applied" as two courses of effort.  But I think that if there's
a renaming on the horizon, maybe we ought to take the opportunity
to correct what I believe is a misnomer: Computer Science.

Thoughts, anyone?
Steve Frysinger
***
Thou art beside thyself.  Much learning hath made thee mad.
		-- Festus (the one in Acts, not Dodge City!)

tla@kaiser.UUCP (03/28/87)

Several recent articles have suggested that the time has come to
separate Computer SCIENCE from Computer ENGINEERING.  I have some
concerns that the administrative and academic separation will lead
to an undesirable conceptual and communication separation not unlike
that that has developed between business oriented data processing
and computer science.  In the later case vocabularies, conceptual
models, and solutions (even to problems that are shared) have grown 
apart.  This is largely because the two camps do not talk to each
other.  The increasing diverging vocabularies makes this gap
accelerate.  Admittedly the problem domains are somewhat different
but where they do overlap it is a shame to reinvent things the other
camp has already invented.

I am worried that emphasizing the separation between CS and CE will
lead to a similar lack of communication and cooperation.  Admittedly
other fields of engineering have maintained reasonable connections
with their underlying scientific collegues (EE and Physics, ChemE
and Chem, ...).

Another recent article also cited the difficulty that most CS
departments are not large enough to maintain strength when divided. 
I wonder if a more reasonable first step is to explore separate
curricula within a single department.  Establish different course
requirements and different degrees but offer each from within a
single department with many faculty participating in both programs. 
Even some courses should be in both programs.  Then if later there
appears to be strong administrative reasons to separate the programs
it can be done.  Having them together also encourages more
discussion of each program by those considering themselves primarily
interested in the other.  This should be healthy as long as neither
group becomes so intolerant as to try to force its views on the
other.


			     --	Terry L Anderson
				AT&T Bell Laboratories -- Liberty Corners
				UUCP:     ...!ihnp4!kaiser!tla
				TeleMail: Terry.Anderson
				(201) 580-4428

edwards@uwmacc.UUCP (03/28/87)

In article <7802@clyde.ATT.COM> spf@bonnie.UUCP (Steve Frysinger) writes:
:You see, though I know there are more liberal definitions, I believe
:that science is the study of what IS by application of the scientific
:method (which I will not belabor, but which is intrinsically
:empirical and NOT inventional).  I've studied some science.
:
:Now, I'm led to reconsider what "computer scientists" do.  Do they
:"discover" algorithms that are floating in Plato's Ideal realm?
:Then they are like mathematicians who "discover" new algebras.
:And maybe this is what some folks mean by science.
:
:I think that without TOO much handwaving I could make a convincing
:argument that most (if not all) of what "computer scientists" do
:(even those researchy folks) can be reduced to algorithms (yes, even
:language theory, though that leans heavily on abstract algebra too).
:
:So, my claim is that there is no computer "science" -- there is
:computer engineering, some research and some applied.
:
:Thoughts, anyone?

 So let me put some words in your mouth. 

 Computer Scientists are just glorified programmers that attempt to
 solve problems (create algorithms) for specific areas of science
 without the benifit of having been really formally trained for it.

-- 
    edwards@unix.macc.wisc.edu
    {allegra, ihnp4, seismo}!uwvax!uwmacc!edwards
    UW-Madison, 1210 West Dayton St., Madison WI 53706

ejnorman@uwmacc.UUCP (03/29/87)

In article <7802@clyde.ATT.COM> spf@bonnie.UUCP (Steve Frysinger) writes:

> Now, I'm led to reconsider what "computer scientists" do.  Do they
> "discover" algorithms that are floating in Plato's Ideal realm?
> Then they are like mathematicians who "discover" new algebras.

Well, I'll just trot out one of my favorite riddles again; it seems
somewhat appropriate to me.

Riddle:
What's the difference between a mathematician and a theoretical
computer scientist?

Answer:
A mathematician knows how to prove things without using induction.

Eric Norman
Internet:     ejnorman@unix.macc.wisc.edu
UUCP:         ...{allegra,ihnp4,seismo}!uwvax!uwmacc!ejnorman
Life:         Detroit!Alexandria!Omaha!Indianapolis!Madison!Hyde
  
"The missionaries may never outnumber the cannibals,
 else they would convert them."
		-- Ken Kunen
--

shebs@utah-cs.UUCP (03/30/87)

>In article <340@ndsuvax.UUCP> ncmagel@ndsuvax.UUCP (ken magel) writes:
>
>At what level should students be taught software engineering principles
>and concerns?  How much should be covered in the introductory courses, 
>how much should be presented to non-majors?  Should the material be a 
>part of courses whose emphasis is another topic (e.g., data structures,
>operating systems), or should there be specific courses which concentrate
> on design, on testing, etc.?

Last fall, I TAed a graduate class in Lisp programming which was 80%
undergrads (ah, the wonders of curriculum reorganization).  Since Lisp
is an easy language to learn, we spent much of our time on style and
larger programs.  We had the idea of making the students change and extend
some programs from week to week, so as to encourage data abstraction.
What a failure.  Wired-in constants, gigantic case statements, you name it,
somebody did it, even after numerous exhortations to the contrary.

A different technique was more effective, though in a rather negative way.
We graded on style, and for the worst offenders, we had this stamp, which
said "VOMIT" in large red letters.  It was appropriate whenever two or more
Lisp hackers concurred in making retching sounds over a piece of code.
People only did such bad things once!  We also got some flak over this,
and a few students got really paranoid, putting apologies and excuses in
their comments.  I think the stamp is probably too abusive to make general
use of, plus reading 300-400 pages of code per week is really awful.

I wonder if the selection process for CS students is flawed.  It seems that
it rewards those who have a good memory for detail and who notice clerical
errors.  Data abstraction seems silly if you believe you can remember all
the details of a program, so students have no motivation for it.  One radical
solution might be to de-emphasize writing programs, and require reading them,
starting with the first course.  I would be interested in hearing if anyone
has tried making a first- or second-year CS class modify programs that were
much too large for them to have written themselves...

							stan shebs

conrad@wucs2.UUCP (03/30/87)

In article <960@wanginst.EDU> ardis@wanginst.UUCP (Mark A. Ardis) writes:
>In article <1285@rti-sel.UUCP> wfi@rti-sel.UUCP (William Ingogly) writes:

>
>There are other MSE-like programs:  Seattle University offers an
>MSE degree, and Texas Christian offers a similar degree.  Dartmouth

	Texas Christian University is a fine school.  (My wife has a
degree in dietetics from there.)  However, unless the TCU CS department has
improved it considerably during the past four years, the degree in
Software Design and Development (or whatever they call it--couldn't
use "engineering" in the title because of Texas law) isn't very good.
When I was in Fort Worth (1980-83) the courses were taught almost
exclusively by workers from local industry, primarily General Dynamics
Corp.  A few of the instructors were probably excellent, but most were
probably poor--because they didn't have the time to "do it right" or
were not technically competent to begin with.  (I didn't take any
courses in the program, but I carpooled with a colleague that
graduated from the program.  As a GD employee "software engineer", I
was also acquainted with several of the people teaching the courses.)

	The above is probably not a fair assessment.  My information
is old.  The SDD program also predated the establishment of their computer
science department.  The CS faculty probably turned their attention to
that program after they got their undergraduate program on-track.
Anyone have more recent information?

	But it does raise a question about "software engineering"
programs.  Where should the faculty come from?  industry? or academia?
Programs that are developed, staffed, and run completely by "academic
types" run the risk of becoming sterile and out of touch with the
everyday world of the practicing "software engineer."  On the other
hand, programs run by "industry types" run the risk of becoming a
rehash of the way things are currently done in industry--which, in
my experience, is often quite poor.  I suppose that the program should
be developed, staffed, and managed by a group drawn from both "types."
The choice of individuals should be selective on both sides.

Conrad Cunningham

eugene@pioneer.UUCP (03/31/87)

In article <1308@uwmacc.UUCP> ejnorman@unix.macc.wisc.edu (Eric Norman) writes:
>
>Riddle:
>What's the difference between a mathematician and a theoretical
>computer scientist?
>
>Answer:
>A mathematician knows how to prove things without using induction.

This is what I heard on Marshall Hall Day at Caltech some years back:
Riddle:
What's the difference between a mathematician and a computer scientist?

Oh, about $10,000 per year ;-).

Addemdum:
Oh, no, that's last years figure, now it's ....... ;-).

From the Rock of Ages Home for Retired Hackers:

--eugene miya
  NASA Ames Research Center
  eugene@ames-aurora.ARPA
  "You trust the `reply' command with all those different mailers out there?"
  "Send mail, avoid follow-ups.  If enough, I'll summarize."
  {hplabs,hao,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugene

ambar@mit-eddie.UUCP (03/31/87)

In article <4428@utah-cs.UUCP> shebs@utah-cs.UUCP (Stanley Shebs) writes:
>
>Data abstraction seems silly if you believe you can remember all
>the details of a program, so students have no motivation for it.  One radical
>solution might be to de-emphasize writing programs, and require reading them,
>starting with the first course.  I would be interested in hearing if anyone
>has tried making a first- or second-year CS class modify programs that were
>much too large for them to have written themselves...
>
>							stan shebs

Here at MIT, the first course in the CS sequence (usually taken as a
second-term freshman or a first-term sophomore) has several
assignments like this.

It is taught in Scheme (a lexically-scoped variant of Lisp), which,
like Lisp, has so little syntax to cope with that having a "clerical
mind" (as Mr. Shebs called it) is really no advantage.

The most fun of the 10 problem sets (spread over a 14-week term) is
the adventure game.  Given the rough skeleton of an adventure game
(say, 5 pages of code), complete, modify, hack....  There is an
optional part to the assignment---adding a "major" modification to the
game.  This is a contest, with prizes to the top 10 or so.

The 9th or 10th (depending on the whim of any given term's lecturers)
problem set is writing a meta-circular evaluator for Scheme.  This
problem set is no joke.  You're handed 10 pages of code, and generate
another 10, easily.

No particular precautions are taken to ensure that students don't
cheat (sure, the TA's make sure you don't copy code)---but there's a
better penalty.  There is no possible way to pass the exams without
having done the problem sets yourself.

Don't blow this article off with "well, that's MIT, but we can't do
that here".  So make half as many problem sets.  Or one big one.  It
really does work here; it's worth trying.
-- 

				AMBAR
ARPA: ambar@eddie.mit.edu		UUCP: {backbones}!mit-eddie!ambar

drk@ihlpg.UUCP (03/31/87)

In article <4428@utah-cs.UUCP>, shebs@utah-cs.UUCP (Stanley Shebs) writes:

> larger programs.  We had the idea of making the students change and extend
> some programs from week to week, so as to encourage data abstraction.
> What a failure.  Wired-in constants, gigantic case statements, you name it,
> somebody did it, even after numerous exhortations to the contrary.

I wonder if this was really a failure.  Unfortunately, one of the best ways
to learn is from your failures.  If people see from actual experience how
their wire-in constants, gigantic case statements, etc, cause real problems
when they try to extend their programs, then it seems to me that half the
battle is won.

To extend this idea of program modification, why not tell students they will
have to modify their first version of a program as a second assignment so
they should do the best job of structuring their program initially.  Then
make them modify it and run into all of the problems with modifying programs.
Then make them go back and rewrite their initial version of the program.
Then make them do another modification.  Seems like this could be very
effective.  In particular, those who do a good job initially, spend the 
least amount of time on the class.
						Denis Kertz
						AT&T Bell Labs
						Naperville, Ill.

shebs@utah-cs.UUCP (03/31/87)

In article <5308@mit-eddie.MIT.EDU> ambar@eddie.MIT.EDU (Jean Marie Diaz) writes:

>Here at MIT, the first course in the CS sequence (usually taken as a
>second-term freshman or a first-term sophomore) has several
>assignments like this.
>
>It is taught in Scheme (a lexically-scoped variant of Lisp), which,
>like Lisp, has so little syntax to cope with that having a "clerical
>mind" (as Mr. Shebs called it) is really no advantage.

I am a great admirer of MIT's course, and SC&IP is one of my books "within
easy reach".

>The 9th or 10th (depending on the whim of any given term's lecturers)
>problem set is writing a meta-circular evaluator for Scheme.  This
>problem set is no joke.  You're handed 10 pages of code, and generate
>another 10, easily.

When I said "large", I meant something over 100 pages of source.  If the
students can even *conceive* of writing it themselves, it's not big
enough.  The idea is that the students will depend on documentation
and comments and organization to be able to *find* the places to tweak,
let alone change them.  This of course presupposes a piece of code
sufficiently well-engineered to unleash on the students...

(Has anybody tried TeX sources?  The purpose of TeX is probably clearer
than say MINIX, whose nature will probably be somewhat obscure to
freshcritters, despite the documentation.  Students could add simple
features to TeX or better yet, whack out something considered useless :-) )

>Don't blow this article off with "well, that's MIT, but we can't do
>that here".  So make half as many problem sets.  Or one big one.  It
>really does work here; it's worth trying.

There have been battles at Utah about whether Pascal or C or Scheme or
PSL is the right first language.  The current compromise is (I believe)
to teach Pascal in the first quarter and first half of second quarter,
and use Scheme for the second half.  The next CS course uses Miranda...
Unfortunately, most of the upper-level courses are wired to C, so (you
guessed it) the graduates all end up as C hackers anyway - sigh...

>				AMBAR
>ARPA: ambar@eddie.mit.edu		UUCP: {backbones}!mit-eddie!ambar

spf@clyde.UUCP (03/31/87)

In article <4428@utah-cs.UUCP> shebs@utah-cs.UUCP (Stanley Shebs) writes:
>One radical
>solution might be to de-emphasize writing programs, and require reading them,
>starting with the first course.  I would be interested in hearing if anyone
>has tried making a first- or second-year CS class modify programs that were
>much too large for them to have written themselves...

Sort of.  In a first semester programming course, and a first course
in data structures and algorithm, my written tests generally have
only one small program or procedure to be WRITTEN by the student,
but three or four programs or procedures to be READ by the student.
With the latter, they would either have to write down the output
given the input, or find the syntax errors, or find the semantic/logic
errors.  This reflected my experience in the lab: people who can't
READ programs are pretty bad at WRITING them, especially when forced
to live with the error messages produced by the VM/CMS compiler (ugh!).

I will confess, it's also easier to grade objectively a reading
problem, rather than reading a student's program and grading it
subjectively.

Steve

kent@xanth.UUCP (04/01/87)

In article <573@kaiser.UUCP> tla@kaiser.UUCP (Terry Anderson) writes:
>Several recent articles have suggested that the time has come to
>separate Computer SCIENCE from Computer ENGINEERING.  I have some
>concerns that the administrative and academic separation will lead
>to an undesirable conceptual and communication separation not unlike
>that that has developed between business oriented data processing
>and computer science.  In the later case vocabularies, conceptual
>models, and solutions (even to problems that are shared) have grown 
>apart.
[...a few more cogent words about the bad effects of the MIS and CS split,
then turns to the proposed split of Software Engineering (SE) from CS.]

I have a radical response (I usually do ;-).  I think that the split of
MIS from CS has had very bad effects.  Rather than further dividing a house
already divided, I think the existing split should be deliberately mended.
(Deliberately as in:  "with all deliberate speed".)

I base this on my own experience (a statistical sample of one ;-), so
forgive the anecdotal approach.

After 20 years of scientific programming, the vicissitudes of keeping a pair
of spouses in widely different fields employed led me to take a job with a
business data processing shop of 200 programmers.

This had two immediate effects.  They found out from me that there was life
after COBOL (yes, I _can_ use it myself), and I found out from them just what
it meant to maintain 6.5 million source lines of code (Virginia's largest
private employer shall remain otherwise unidentified, but it's a BIG
operation.)  I was the only person in the shop with formal training in software
engineering, and a true dedication to its methods and principles.  I was also
(barring a few new hires) the only one there who had neither instincts nor
experience in applying it where it is really needed, in the large job shop.

They had _excellent_ software configuration control, quality assurance, test
and integration, planning and management, training, a pretty good _paper_
tracking system, and were generally successful.

I got to help plan and implement a mainframe vendor change from a 36 to a 32
bit machine, data conversion, code conversion, 4th generation language
adoption, a new DBMS, and lots more.  Very exciting times for a FORTRAN
retread!  I learned more from them (they _outnumbered_ me!) than I was able
to return.

Pertinent to this discussion, I learned that software engineering, no caps,
is working just fine out there in the trenches, among folks who invent it
for themselves as they go along, out of necessity and a few useful articles
in the business software rags.

But, when the marriage and then the job went bust, and I came back to
college, I found that the SE types do not have what they consider a single
example of a major system successfully constructed using SE methods -- you
know, on time, under budget, meeting or exceeding all specs; the holy grail.

The place I worked was sure interested in keeping costs in line, and had
watched the data processing part of their budget grow without seeming bound,
but it was attributable more to increasing computerization of manual
systems, than to problems of software management.

So, I would like to propose that CS, SE, and MIS need to be back under one
roof, so that the experiences of the workplace can be joined with the
efforts of academe, and we start learning what the other knows again.  SE
seems mordibund to me (but maybe I'm just impatient ;-), perhaps a bit of
hybred vigor would get things moving toward useable, realistic methods and
tools.  Having the CS/SE undergraduates co-oping in a shop where code comes
in boxcar loads of tapes would do wonders for their understanding of the
need for controls and productivity enhancers and innovative communication
methods.  _I_ write 10,000 line chunks of code; tossing one off as a project
now, in Ada, for fun.  But don't expect a million line suite out of me or
any mortal; that is the level where SE, when it works, will be in its
proper area of application, and business MIS is where those code suites
exist now, alive and ready for study and improvement.

Comments welcome; flames at your own risk.

	( Napalm?  Check.  Igniter?  Check.  Return address?  Check. ;-)

Kent.			<<The Contradictor>>		(kent@xanth.UUCP)

Arrgh!  Dawn.  Back to the crypt....

kwe@bu-cs.UUCP (04/01/87)

In article <1285@rti-sel.UUCP> wfi@rti-sel.UUCP (William Ingogly) writes:

> There are, I think, a few programs in software engineering 
>around. For example, there's the Wang Institute for Graduate Studies 
>in Tyngsboro, Mass. that offers a Master's degree in software 
>engineering. Anyone know of any other S.E. programs?
>

	Unfortunately, the Wang program is no more.  Wang has been
forced to give up the Wang Institute because of Wang's money problems.
Boston University is taking over the facility in Tyngsboro and
responsibility for graduating the students, but I don't think the
Software Engineering program will continue.  Dr. Wang created the
Institute precisely because he could not find the software engineers
that he wanted, even in the Boston area.  Wang's program was ambitious
and, unfortunately, gold-plated.

	There is ample opportunity for Software Engineering programs,
but the students and the companies have to be convinced that it
is better than a good CS or EE program.

         --------------------------------------------
        |       Kent W. England                      |
        |       Network & Systems Engineering Group  |
        |       Boston University                    |
        |       Information Technology               |
        |       111 Cummington Street                |
        |       Boston, MA      02215                |
        |       (617) 353-2780                       |
        |       kwe@buit1.bu.edu        internet     |
        |       itkwe@bostonu           BITNET       |
         --------------------------------------------
  


-- 
	 --------------------------------------------
	|	Kent W. England                      |
	|	Network & Systems Engineering Group  |
	|	Boston University                    |
	|	Information Technology               |
	|	111 Cummington Street                |
	|	Boston, MA      02215                |
	|	(617) 353-2780                       |
	|	kwe@buit1.bu.edu	internet     |
	|	itkwe@bostonu		BITNET       |
	 --------------------------------------------
     

elg@killer.UUCP (04/03/87)

in article <7916@clyde.ATT.COM>, spf@bonnie.ATT.COM says:
> In article <4428@utah-cs.UUCP> shebs@utah-cs.UUCP (Stanley Shebs) writes:
>>One radical
>>solution might be to de-emphasize writing programs, and require reading them,
>>starting with the first course.  I would be interested in hearing if anyone
>>has tried making a first- or second-year CS class modify programs that were
>>much too large for them to have written themselves...
> 
> but three or four programs or procedures to be READ by the student.
> With the latter, they would either have to write down the output
> given the input, or find the syntax errors, or find the semantic/logic
> errors. 

FIND SYNTAX ERRORS? Talk about DISGUSTING... one thing that irritated me
greatly in my intro CS class was semicolon-bashing on Pascal programs (and at
the time, my Pascal was a bit rusty, because I'd spent the last couple of
years in "C", BASIC, and 6502 assembly language). What you get is those
"clerical minds" again -- people who memorize the nit-picking details
of Pascal syntax, and teachers who look for the most obscure code they
can find (which is a VERY bad example -- some of those pascal programs
looked like they'd won USENET's annual Obfusticated "C" contest, and who
knows, maybe some of those impressionable students got the wrong
impression?). Everybody knows that when you have a question about
syntax, you look it up in a book, or look at the generated assembly
language to make sure it's doing what you want it to do.

> This reflected my experience in the lab: people who can't
> READ programs are pretty bad at WRITING them, especially when forced
> to live with the error messages produced by the VM/CMS compiler (ugh!).

Possibly. But digging up buggy, obfusticated code and telling people to "trace
the output" isn't going to help anybody do anything.  I must admit that I
learned most of my "C" by reading sources posted to the net (e.g. "Larn"), and
frantically flipping thru my "C" book trying to figure out what was going on
(ok, so I cheated at Larn, kill me :-). But that kind of activity has no
relation to the usual "here's ten lines of bletcherous code, tell me what's
wrong with it" type of thing.

 * Airwick *

--
Eric Green   elg%usl.CSNET     Hacker-in-training, University of SW Louisiana
{cbosgd,ihnp4}!killer!elg      
Snail Mail P.O. Box 92191          May you have the wisdom to see what must
Lafayette, LA 70509                be done, and the strength to do it.

ccplumb@watnot.UUCP (04/03/87)

shebs@utah-cs.UUCP (Stanley Shebs) writes:
>Data abstraction seems silly if you believe you can remember all
>the details of a program, so students have no motivation for it.  One radical
>solution might be to de-emphasize writing programs, and require reading them,
>starting with the first course.  I would be interested in hearing if anyone
>has tried making a first- or second-year CS class modify programs that were
>much too large for them to have written themselves...

Don't forget that any 1st-year class will include a certain number of
people who make a hobby of removing (most intricately written, and
*completely* undocumented) copy protection from programs.  These types
are *very* good at remembering details.  I've seen many `infinite
free men' hacks to commercial games, and these people are adding
features to binaries they're not `supposed' to be looking at anyway,
without benifit of anyone's data abstraction techniques.

>ambar@eddie.MIT.EDU (Jean Marie Diaz) writes:
>>The 9th or 10th (depending on the whim of any given term's lecturers)
>>problem set is writing a meta-circular evaluator for Scheme.  This
>>problem set is no joke.  You're handed 10 pages of code, and generate
>>another 10, easily.
>
>When I said "large", I meant something over 100 pages of source.  If the
>students can even *conceive* of writing it themselves, it's not big
>enough.  The idea is that the students will depend on documentation
>and comments and organization to be able to *find* the places to tweak,
>let alone change them.  This of course presupposes a piece of code
>sufficiently well-engineered to unleash on the students...

Is 100 pages large enough?  I wrote 54 pages of assembler in
2 months' spare time.  This was for a VAX, running Unix, neither
of which I had used more than a month and a half when I started.
(I really ought to finish the thing... it works, but there are
some bits which are ungodly ugly.  That should bring it up to
*at least* a hundred pages.)  Speaking as a first-year CS student,
I could conceive of writing a Unix kernel.  (From what I know of
the job, it'd take me years, but I don't think the people who write
the things are a higher order of being or anything.)  GNU emacs
is about where I start to boggle at the size of things.  (I could,
I think, still write such a thing, but I'd have to learn how to
attack the problem first.)

>(Has anybody tried TeX sources?  The purpose of TeX is probably clearer
>than say MINIX, whose nature will probably be somewhat obscure to
>freshcritters, despite the documentation.  Students could add simple
>features to TeX or better yet, whack out something considered useless :-) )

I've always wanted to be able to add format characters to macro
parameters, so \def\foo#1{...} would pick up the next indivisible
element in the input stream in #1, while \def\foo#d1{...} would
pick up the next <dimen>. #i1 would pick up the next integer,
#n1 would pick up the next real number, etc.  Perhaps this could
be attempted?  The parsing routines are already in TeX, thay just
need to be put to use.

Of course, you can always add Yet Another Feature to GNU emacs.
That should be a big enough program for anybody.  (Finding a
feature that isn't there already could be a challenge, however.)

There is also the opposite problem of producing an assignment
that some couldn't handle.  Remember that, in order to modify
TeX, you have to know web, which means both TeX and Pascal,
and the gnumacs lisp is essentially undocumented.

If you want something really funny to think about, consider that
neither TeX nor GNU emacs are big enough to be true tests of
software engineering.  After all, experience proves that they
aren't too big to be written by just one person...
--
	-Colin Plumb (watmath!watnot!ccplumb)

Silly quote:
He hit the nose right on the head.

colsmith@ihu1e.UUCP (04/04/87)

In article <4428@utah-cs.UUCP>, shebs@utah-cs.UUCP (Stanley Shebs) writes:
>  One radical
> solution might be to de-emphasize writing programs, and require reading them,
> starting with the first course.  

That is a really good idea.  In my first "hard" programming class (the
programs got too involved to write the whole thing the night before :-) )
the teacher had one "reading code" exam.  He would give us a 10 page
program with few or no comments and make us answer questions about what
different procedures did and etc.  It was horrible, and people rarely
finished it, but it was very enlightening.

This same teacher also almost killed us for hard coding things and etc.  We
all thought he was cruel (Hi Jerry!) but afterwards we realized we learned
an awful lot about programming from him.  He also used the very good
technique of making you recycle earlier programs.

Marcia Colsmith

shebs@utah-cs.UUCP (04/06/87)

In article <734@killer.UUCP> elg@killer.UUCP (Eric Green) writes:

>...I must admit that I
>learned most of my "C" by reading sources posted to the net (e.g. "Larn"), and
>frantically flipping thru my "C" book trying to figure out what was going on
>(ok, so I cheated at Larn, kill me :-). But that kind of activity has no
>relation to the usual "here's ten lines of bletcherous code, tell me what's
>wrong with it" type of thing.

Certainly students should be given only the best programs to read at first,
then maybe a bad one later, when they've learned what to retch and puke on...
In fact, adding a new critter or command to Larn could be very educational
(but I don't know if Larn is a "best program"!)

Finding out what's wrong with an ten line *algorithm* is a very important
task.  All the formal methods in the world can't prevent the mistaken
counting that leads to fencepost errors, and those sorts of bugs are
inevitably encountered by someone other than the original author....

>Eric Green   elg%usl.CSNET     Hacker-in-training, University of SW Louisiana

							stan shebs
							shebs@cs.utah.edu

dan@applix.UUCP (04/06/87)

Has anyone tried to drive home the importance of design and documentation by
forcing students to significantly modify someone else's project?  This could
be done either by trading projects in mid-course or by giving students in one
course the final project from a previous (possibly different) course as a 
starting point.

						dan
...!decvax!frog!halleys!applix!dan

beth@brillig.UUCP (04/07/87)

>Dan Pierson (...!decvax!frog!halleys!applix!dan) asks:
>Has anyone tried to drive home the importance of design and documentation by
>forcing students to significantly modify someone else's project?  This could
>be done either by trading projects in mid-course or by giving students in one
>course the final project from a previous (possibly different) course as a 
>starting point.

Yes, last spring as part of a course called "Software Design and Development
with Ada", my students modified two programs.  The purpose of the project
was two-fold (at least).  First, as part of my dissertation, I am trying to
evaluate the effects of design techniques on modularity and the effects of
modularity on maintainability.  Second, it seemed to be a good way for the
students to get their hands on bigger pieces of code early in the class. 

The programs (a text formatter and an electronic mail system) were written
by graduate students as part of the study.  We used four text formatters
and three mail systems in the maintenance study.  Each student changed one
version of each program.  I seeded a fault to cause a particular failure
in each system.  We asked the students to repair the fault (given a
failure report) and make two enhancements.

This project isn't quite what Dan had in mind.  We didn't give the students
the design documentation.  However, the project did drive home the importance
of meaningful variable names, sufficient in-line documentation, appropriate
modularity, and a vague idea of 'what Ada programs should and should not be'.
I would like to think that their group projects were better than they
would have been because the students did this maintenance work.  The 
students didn't like the programs all that much, but they thought the
project was useful.  [As an aside, as far as I know, they didn't cheat.
They knew I was monitoring what they were doing and that I was on the
machine quite a bit.  They also knew that their friends didn't necessarily
have the same program to change.]

In retrospect, I would give the students better programs to modify.  I
believe that reading good programs is one way of learning how to write
good programs (must be my literature upbringing).  But how many of us
have changed absolutely horrible programs?  It is an enlightening
experience.  Maybe I would give them one of each.  But the underlying
purpose of giving the programs the way we did was as part of the
experiments for my dissertation.  As a purely educational exercise, I'm
not sure which approach I would take.

				Beth Katz
				Dept. of Computer Science
				Univ. of Maryland - College Park
				beth@brillig.umd.edu

ps. The results from this should be available in a reasonable form
sometime this summer.

shebs@utah-cs.UUCP (04/13/87)

In article <12788@watnot.UUCP> ccplumb@watnot.UUCP (Colin Plumb) writes:

>Is 100 pages large enough?  I wrote 54 pages of assembler in
>2 months' spare time.  This was for a VAX, running Unix, neither
>of which I had used more than a month and a half when I started.
>(I really ought to finish the thing... it works, but there are
>some bits which are ungodly ugly.  That should bring it up to
>*at least* a hundred pages.)  Speaking as a first-year CS student,
>I could conceive of writing a Unix kernel.

Careful, you'll find yourself a job before the month is out!  There
are always going to be a few people capable of handling any programming
job.  Most of the arguments about engineering practice are pretty weak
in such cases.  All the instructor can or should do in those cases is
to demand that amazing feats of programming be understandable to
normal people, give the students free access to extra computing
power, and let 'em rip.  For better or worse, it's the "super-programmers"
that produce the bulk of systems software that we use...  BTW, is your
54 pages of code readable?  And did you really say that you *wrote*
assembler code?  I can and have written plenty of assembly language,
but it's not a skill I'm proud of...

>There is also the opposite problem of producing an assignment
>that some couldn't handle.  Remember that, in order to modify
>TeX, you have to know web, which means both TeX and Pascal,
>and the gnumacs lisp is essentially undocumented.

That's why I said "well-engineered".  Web is mostly a kludge to get
around OS and Pascal limitations - nobody I've worked considers it to
be worthwhile in a Un*x environment.  It's too bad one gets fewer
academic brownie points for writing good software than for writing
good textbooks...

Just another thought - for something like TeX that's not so easy to
modify, have the students explain an obscurity or justify a limitation.
Lots of room for essay-type problems, especially on tests!

>If you want something really funny to think about, consider that
>neither TeX nor GNU emacs are big enough to be true tests of
>software engineering.  After all, experience proves that they
>aren't too big to be written by just one person...

I believe the ratio is more important than absolute size.  An upper-level
SE course should definitely work with systems in the million-line range,
but non-proprietary ones are hard to come by...

>	-Colin Plumb (watmath!watnot!ccplumb)

							stan shebs
							shebs@cs.utah.edu

ambar@mit-eddie.UUCP (04/15/87)

In article <12788@watnot.UUCP> ccplumb@watnot.UUCP (Colin Plumb) writes:
>
>There is also the opposite problem of producing an assignment
>that some couldn't handle.  Remember that, in order to modify
>TeX, you have to know web, which means both TeX and Pascal,
>and the gnumacs lisp is essentially undocumented.

Well, the documenting of GNUlisp proceeds apace (contact
gnu-manual-request@a.cs.uiuc.edu for more information.)  As for TeX,
why not use the version translated to C by Pat Monardo
(monardo@renoir.berkeley.edu)?

-- 

				AMBAR
ARPA: ambar@eddie.mit.edu		UUCP: {backbones}!mit-eddie!ambar

ccplumb@watnot.UUCP (04/15/87)

shebs@cs.utah.edu.UUCP (Stanley Shebs) says (in <4480@utah-cs.UUCP>):
>In article <12788@watnot.UUCP> ccplumb@watnot.UUCP (Colin Plumb) writes:
>
>>Is 100 pages large enough?  I wrote 54 pages of assembler in
>>2 months' spare time.  This was for a VAX, running Unix, neither
>>of which I had used more than a month and a half when I started.
>>(I really ought to finish the thing... it works, but there are
>>some bits which are ungodly ugly.  That should bring it up to
>>*at least* a hundred pages.)  Speaking as a first-year CS student,
>>I could conceive of writing a Unix kernel.
>
>Careful, you'll find yourself a job before the month is out!

Hey, I'm *looking* for a job!  Give me a buzz if you want a junior
systems type.  I'm interested in everything down to the silicon
level.

>							       There
>are always going to be a few people capable of handling any programming
>job.  Most of the arguments about engineering practice are pretty weak
>in such cases.

While I'm glad you think so highly of my skill, I haven't noticed it
being *that* uncommon.  (Then again, perhaps it's just the types I hang
around with, and the fact they're mostly 4th year.)

>		 All the instructor can or should do in those cases is
>to demand that amazing feats of programming be understandable to
>normal people, give the students free access to extra computing
>power, and let 'em rip.

Hey, I like that!  So far, my quest for more computing resources has only
earned me the ire of a hunk of the local systems people.  There is still
the problem (that a job might fix) that hacking is to be done in intense
bursts, and classes gum those up rather badly.  They stubbornly refuse to
be resheduled for 4:00 am two days hence.

>			  For better or worse, it's the "super-programmers"
>that produce the bulk of systems software that we use...

Going on the theory that having no systems software would be worse,
I can argue that it's for the better.  Also, no amount of preplanning
can supply the unity of approach achieved by having one mind do everything.

>							  BTW, is your
>54 pages of code readable?

Well, I just put in about an hour and a half documenting and commenting
the thing, and doubling that should produce a comprehensible program.
I'll send a copy to anyone who's interested.  I could probably use some
*intelligent* comments on my commenting style.

>			     And did you really say that you *wrote*
>assembler code?  I can and have written plenty of assembly language,
>but it's not a skill I'm proud of...

What do you mean, `did I really *write* assembler code'?  Is there another
way to produce it?  (Snarfing cc -S doesn't count!)

>>There is also the opposite problem of producing an assignment
>>that some couldn't handle.  Remember that, in order to modify
>>TeX, you have to know web, which means both TeX and Pascal,
>>and the gnumacs lisp is essentially undocumented.
>
>That's why I said "well-engineered".  Web is mostly a kludge to get
>around OS and Pascal limitations - nobody I've worked considers it to
>be worthwhile in a Un*x environment.  It's too bad one gets fewer
>academic brownie points for writing good software than for writing
>good textbooks...

Hm... doesn't the question of `what is "well-engineered"?' lead us full
circle to what should be taught in SE classes?

While the purpose of web may be to kludge around language and OS
limitations, I don't think you can call it a kludge itself.
Redundant is one thing.  Bad is another.  (Unless you're short on
disk sapce! :-))

Anyway, does Knuth *need* academic brownie points?  I couldn't imagine
who he needs to keep happy.  (Besides the general public, who have
been awaiting Vol. 4 for Some Time Now.)

>Just another thought - for something like TeX that's not so easy to
>modify, have the students explain an obscurity or justify a limitation.
>Lots of room for essay-type problems, especially on tests!

Yeah, that sounds about hard enough... It'd take me a while to grok the code
well enough to explain why (for example) TeX has so many *separate* memory
free lists.

>>If you want something really funny to think about, consider that
>>neither TeX nor GNU emacs are big enough to be true tests of
>>software engineering.  After all, experience proves that they
>>aren't too big to be written by just one person...
>
>I believe the ratio is more important than absolute size.  An upper-level
>SE course should definitely work with systems in the million-line range,
>but non-proprietary ones are hard to come by...

What do you mean by `ratio'?  Anyway, I agree with the million-line range.
That's big enough to require several levels of thinking about the program.

The non-proprietary problem is non-trivial.  Maybe with GNU we can start
courses on OS internals again.

>							stan shebs
>							shebs@cs.utah.edu
--
	-Colin Plumb (watmath!watnot!ccplumb)

Silly quote:
Don't just stand there like a sitting duck.

dickey@ssc-vax.UUCP (Frederick J Dickey) (04/15/87)

> 
> When I said "large", I meant something over 100 pages of source.  If the
> students can even *conceive* of writing it themselves, it's not big
> enough.  The idea is that the students will depend on documentation
> and comments and organization to be able to *find* the places to tweak,
> let alone change them.  This of course presupposes a piece of code
> sufficiently well-engineered to unleash on the students...

When I was a student at Ohio State, I took a course whose assignments
involved a brain-damaged assembler. The assignments were to unbrain-damage the
assembler by adding various features. I found out that I could do this without 
having any idea of how the assembler worked. I also had a job for awhile where
I maintained a Fortran compiler. I made several fixes to the compiler without
ever figuring out how it worked. I know that my fixes worked because I was 
where the people who used it could come and shoot me if it didn't. I'm
still alive.

Consider an analogy with reading and writing. Most people can read. That seems
to be a fairly easy skill to pick up. Most people can't write (ever try to
read your average tech report?). Is teaching programming like teaching reading
or teaching writing? I suspect there are a lot of similarities between 
writing and programming. To write something, you have to know what you are
going to say and how you are going to say it. To program something, you
have to know what the program is supposed to do and how to do it.

=======> Fred

dickey@ssc-vax.UUCP (04/15/87)

In article <427@applix.UUCP>, dan@applix.UUCP (Dan Pierson) writes:
> Has anyone tried to drive home the importance of design and documentation by
> forcing students to significantly modify someone else's project?  This could
> be done either by trading projects in mid-course or by giving students in one
> course the final project from a previous (possibly different) course as a 
> starting point.





When I was a computer science TA, I used to make a big deal about
commenting programs. Once, I had a student turn in a program with so
many comments, I had a hard time finding the program.

=========>

shebs@utah-cs.UUCP (04/17/87)

In article <1188@ssc-vax.UUCP> dickey@ssc-vax.UUCP (Frederick J Dickey) writes:

>Consider an analogy with reading and writing. Most people can read. That seems
>to be a fairly easy skill to pick up. Most people can't write (ever try to
>read your average tech report?). Is teaching programming like teaching reading
>or teaching writing? I suspect there are a lot of similarities between 
>writing and programming. To write something, you have to know what you are
>going to say and how you are going to say it. To program something, you
>have to know what the program is supposed to do and how to do it.

(Hi Fred!) I agree completely, though your "can't write" presumably means
"can't write coherently", at least going by the average Boeing document :-).
You don't mention the situation where students can write without being able
to read, rare in grade school natural language, near-universal in college
CS courses.  If reading is easier to pick up, then wouldn't it be better
pedagogy to start off with reading and introduce writing a little later?

Many professional writers seem to do what is to me an incredible amount of
reading, and in fact the best programmers I know also read quite a bit of
each other's code.  In fact, not too long ago somebody in this group was
declaring that they learned C by studying "larn" code...

>=======> Fred

								stan

dickey@ssc-vax.UUCP (Frederick J Dickey) (04/20/87)

In article <4502@utah-cs.UUCP>, shebs@utah-cs.UUCP (Stanley Shebs) writes:
> 
> (Hi Fred!) I agree completely, though your "can't write" presumably means
> "can't write coherently", at least going by the average Boeing document :-).
> You don't mention the situation where students can write without being able
> to read, rare in grade school natural language, near-universal in college
> CS courses.  If reading is easier to pick up, then wouldn't it be better
> pedagogy to start off with reading and introduce writing a little later?
> 
> Many professional writers seem to do what is to me an incredible amount of
> reading, and in fact the best programmers I know also read quite a bit of
> each other's code.  In fact, not too long ago somebody in this group was
> declaring that they learned C by studying "larn" code...
> 
I am willing to concede that a lot of programmers learned to code by reading
code. But turning to the natural language analogy, as near as I can tell,
there are a lot of people who read a lot but can't write (coherently). 
The secret to learning how to write is to write. It is helpful to have
models to imitate. I believe it is the case that everyone who goes through
the American educational systems is forced to read some "masterpieces
of English literature." However, very few people can write masterpieces.
Reading and writing are just plain different skills.

The problem with "teaching programming by maintaining 
code" is that it is in a classroom setting with fairly clear "success"
criteria. My personal experience is that you can satisfy the success
criteria without understanding the code that you are "reading." 
Thus, whatever the merit of the idea in principle, it won't work in
practice because the students are evaluated on the basis of metrics
which measure comprehension of the code only in the most indirect way.

At one time, the study of Latin was justified on the basis that it taught
"logical thinking." The current philosophy seems to be that if you want
to learn logical thinking, take a logic course. In other words, if you
want to learn A, take a course in A not B. If reading code is such a great
idea, it would seem that there ought to be courses like "CS 105 - Great
Masterpieces of the Unix literature."