🚀 go-pugleaf

In article <376@cherry5.UUCP> murphyn@cell.mot.COM (Neal P. Murphy) writes:
Various real-world analogies such as:
> Could you add a manual choke cable to your car's engine?

I don't follow the basic analogy -- are you postulating a class of people
who are sufficiently trained in automotive engineering to design an engine,
but not sufficiently trained to install a choke cable in one?

>Students are in a similar position.  While they have may have solidly mastered
>the basics, they have yet to learn how to make a good, fine, large software
>system.  They couldn't possibly learn enough about the system to be modified to
>properly make the changes.  I've been in this field for 10 years, and *I've*
>just spent a month and a half reading 500 pages of source code and 500 pages of
>documentation just to add features X and Y to a product here at Motorola.  I am
>now at the point where I can make those changes. Students must learn how to make
>a good product first. Once they have mastered that, then they can learn how to
>enhance existing products. But by the time they get to that point, they have
>already graduated and are in industry.

I must disagree with some of the assumptions here.  I believe that if the 
software in question is correctly engineered, then a competent student with
a solid mastery of the basics should be able to perform simple maintenance
on that system.  This assumes, by the way, that "the basics" includes some
knowledge of what constitutes "correct engineering".  Unfortunately, this is
not the case, and I've seen very few real-world systems that are in fact
engineered to such a standard.  Within that constraint, I'll agree that
making significant changes to a system that is inadequately documented,
not clearly structured, etc. can stretch the abilities of the most capable 
programmer.  Without any knowledge of the system you are dealing with or
the complexity of "X and Y", I'll venture to state that there are things
the previous writers/maintainers of the system could have done that would
have made it easier, probably significantly easier, for you to make your 
changes.

Students can't learn to make a good product if they don't know what one is.
A major component of what makes a product good is its maintainability.  To
be able to write a program that does what it is intended to do, and do it
well (by whatever metric) is important, but it is also important that others
be able to easily alter it later.  There is generally some perception that
this is desirable, but without hands-on experience maintaining other people's
code, things like commenting, roadmaps, design documentation, and the like
are just rules to be followed (and, like as not, dropped as soon as they're
not being graded on).

This doesn't address the problem of coming up with example systems to make
these maintenance assignments on, I admit that's tough.  Of course ideally
there would be two versions of the assignment: the first time, making a minor 
change on a typical (i.e. not bad or buggy, just not engineered for continuing
maintenance) system, the next assignment to make a change of a similar 
magnitude to a fully-engineered, well-documented system.  [In my day, before
the goto wars had been fought and won, there was typically an assignment 
early on to make some change to (or just decipher) a "spaghetti-code" program,
contrasted with the "structured" version; this is a similar exercise at the
software engineering level].

One possibility that seems somewhat promising: in a class which has a longterm
ongoing project (a compiler, perhaps), have students swap off source code at
each iteration, so each increment of change is to someone else's code.  It
would be best if the project were such that considerable variation in design
and structure were possible, so that your predecessor's code might not be 
structured just like yours.  Needs some development, and I should get back to
work...
-
Jim Perry   perry@apollo.com    HP/Apollo, Chelmsford MA
This particularly rapid unintelligible patter 
isn't generally heard and if it is it doesn't matter.