🚀 go-pugleaf

In article <78584@linus.UUCP>, mitchell@community-chest.uucp (George Mitchell) writes:
> In article <11064@cbnews.ATT.COM> kww@cbnews.ATT.COM
> (Kevin W. Wall,55212,cb,1B329,6148604775) writes:       `Just once I'd
> `like to see a homework assignment in some CS course be something like
> `
> `	"add features X and Y to this 60,000 software system (which the
> `	students have never seen before) and turn it in next week".
> 
> Would someone (or more) please address why this is not done.
> --

There are a few important reasons why this is not done often in CS courses.

1. The proper subject material for routine courses must be in some sense
widely received and well-understood material. It is not a good idea to 
give an assignment like this unless you can really treat the issues that may
come up.

The methods that are being developed for dealing with this problem seem to
me controversial. From an academic point of view, one may very well argue
that the 60,000 line system can either be treated in a localized, (i.e.
weakly interacting pieces much less than 60,000 lines long) manner. If this
is not the case, then one can argue that the system is much more seriously
flawed than lacking features 'X and Y'.

One might also encounter the belief that if features 'X' and 'Y' are not
easily implemented and it's hard to figure out what the 60,000 lines of
code really do (in detail) then it may not be safe or acceptable to add 
'X' and 'Y'. 

It will not satisfy the students to tell them that the real world is like
this, and they will have to do sub-sensible compromises as professionals.
You will have to (if you are an intellectually honest professor) arrive
at a good example of a 60,000 line piece of code, not fatally flawed from
the start, and desirable missing features 'X' and 'Y'. Whitewashing the
unretouched output of some code generator generator is not likely to teach
your students very much other than this type of work should be avoided.


2. The project may not fall within the grasp of even good undergraduate
students. Their curriculum needs to treat other important issues first,
such as basic programming, fundamental algorithms, data structures, 
formal languages, operating systems, computer architecture, compilers and
interpreters, and principles of software design (including ideas of 
correctness, performance, and specification). It is not clear to me that 
you can expect two full semesters in each of these, and I don't think
there is room for the large-scale maintenance problem in the first semester
of any of them. So perhaps this is for graduate students.

3. As for graduate school, you might give such an assignment, but in the
universities where I have been a professor (University of New Mexico,
State University of New York at Buffalo), students were acquiring enough
experience not to need this assignment or they were hopeless enough not to
profit by it. The people in my experience who had the greatest difficulty
dealing with large scale assignments were the people who worked full time
as systems programmers at the computer center: their problem was often that
they knew how much sleaze was out there 'in the real world' and they were
trying to get away with a widespread but unacceptable practice where a well
founded solution was equally near at hand. 90% of the code in the world is
written by people not fit to teach the language they code in, especially at
the graduate level, which means that often the only lesson reliably drawn
from real world code is how much computer science has advanced since the 
authors of the real world code were educated.

4. The 60,000 line program is likely to seem to graduate students like a
program they are developing/maintaining for the benefit of the professor
if the program is real. There have often been cases where a graduate
computer science department has arrived at a large scale piece of software
as the result of countless hours of graduate labor. In order for this to
be a fair arrangement, the software work should be paid for, perhaps in 
terms of a research assistantship or stipend, which is not generally
available to all students. Then the students who have not been awarded
support should not be required to contribute work to such projects, and
yet they should not be excluded from any courses simply because they are
not supported. Thus the large scale program maintenance should not be in a
course. It is likely that those students interested in software maintenance
will seek to work for a professor who will provide them with this kind of
experience, so although this kind of work belongs outside a course, it
is often found in a serious computer science department.


Later,
Andrew Mullhaupt

P. S. I was a professor of applied mathematics, with a large amount of my
work in computation, but I still count my code in the 90% written by 
non-experts in the language because I am required (by the circumstances of
my present employment) to write code in APL, a language I am philosophically
opposed to. I don't think my code is bad, but you would learn a somewhat
idiosyncratic style of APL if you read mine.