jeff@samna.UUCP (jeff) (03/16/90)
In article <1175@dftsrv.gsfc.nasa.gov> xrtnt@amarna.gsfc.nasa.gov writes: >[ Scheme to have different classes of students working together on a project described ]. >There are a few interesting things that you can do with such a program... >you could teach the importance of reuse (same project thread for the series... >code you worked on as a sophmore could be used when you are a senior), >maintainablity, readablity, good high level design, etc. I think that if you >can make these points early students are more likely to use them as >professionals. After all if you get burned by sloppy code you wrote as a >sophmore when you a junior or senior you are less likely to do it in real life. This is an interesting idea but if you're going to require that code from last year be re-used, I think you need to start with a little more experience. Code I produced after nothing but a couple of introductory courses and a basic data-structures course was, I'm sure, not very pretty. I don't think I would've wanted to get stuck maintaining it - I'd have ended up wasting too much time rewriting my sophomore-level code. (Note: I don't want to start a sophomores-can-write-good-code-too flame-war - I'm only speaking for myself). I find the concept interesting though (I never had course involving a group software project when I was in school). Jeff
perry@apollo.HP.COM (Jim Perry) (03/19/90)
In article <210@samna.UUCP> jeff@samna.UUCP () writes: >In article <1175@dftsrv.gsfc.nasa.gov> xrtnt@amarna.gsfc.nasa.gov writes: >>[ Scheme to have different classes of students working together > on a project described ]. > >>There are a few interesting things that you can do with such a program... >>you could teach the importance of reuse (same project thread for the series... >>code you worked on as a sophmore could be used when you are a senior), >>maintainablity, readablity, good high level design, etc. I think that if you >>can make these points early students are more likely to use them as >>professionals. After all if you get burned by sloppy code you wrote as a >>sophmore when you a junior or senior you are less likely to do it in real life. > >This is an interesting idea but if you're going to require that code from >last year be re-used, I think you need to start with a little more >experience. Code I produced after nothing but a couple of introductory >courses and a basic data-structures course was, I'm sure, not very pretty. >I don't think I would've wanted to get stuck maintaining it - I'd have >ended up wasting too much time rewriting my sophomore-level code. Surely that's part of the point. Looking at the flip side, code you produced after nothing but[...] was probably not very complicated or difficult (in retrospect--of course it seems so at the time). The ability to analyze a piece of code and decide it's bad enough or enough of a tar-baby that you'd be better off rewriting it is quite valuable. Acquiring that ability requires some pain and suffering, but it's hardly wasted time. And, of course, if you know how to recognize such code you know at least what to strive for in your own work. The issue of how to teach this sort of meta-programming (maintainability, readability, flexibility, reusability...) comes up here from time to time. It would appear that the benefits and motivation for this sort of thing only appears with experience, and experience of "continuing engineering" rather than new program development. So far there haven't beenj many practical solutions: this sort of long-term broad approach would require a whole department's collaboration, and is not going to make students happy in the short term. [I missed the earlier discussion on this thread; maybe someone's solved it]. This may be the sort of thing that can't be taught at this level, and good behaviors must be instilled without deep understanding. Just as we instill an absolute eschewal of GOTOs, we must enforce standards of documentation (comments), style, readability, design, etc. Students may balk at these (to them) arbitrary and capricious rules, but they'll follow them if the grade is on the line. The understanding behind the rituals may not come until later. One problem in an undergraduate environment may be finding graders who understand the deeper truth, and can reasonably judge compliance. One eye-opening experience is the first time you are called upon to make an enhancement to a significant program that doesn't follow these "aribtrary" rules, for instance is well-designed and structured, but completely undocumented. I agree with the original poster, that the effect is significantly enhanced when it is one's own code (and one's own code, a year or two old, may as well be that of a stranger). A pet peeve of mine is the observation that while textual coding style seems to be well-established, i.e. CS programs seem to be producing programmers who consistently indent their code and generally adhere to consistent conventions (to the point of religious fervor, probably due to the sort of ritual enforcement I mentioned), there is very little consistency (or general presense) of documentation. It's probably easier to enforce and motivate indentation, and I'm all for it, but you can always mechanically reformat a program; there's no way you can deduce what it's intended to do (as opposed, for instance, to what it does :-). - Jim Perry perry@apollo.hp.com HP/Apollo, Chelmsford MA This particularly rapid unintelligible patter isn't generally heard and if it is it doesn't matter.
lws@comm.WANG.COM (Lyle Seaman) (03/21/90)
perry@apollo.HP.COM (Jim Perry) writes: >they'll follow them if the grade is on the line. The understanding >behind the rituals may not come until later. One problem in an >undergraduate environment may be finding graders who understand the >deeper truth, and can reasonably judge compliance. Perhaps. In my case, I was one of these graders, and after several years of 'industry experience' [what a losing requirement for a job!] I honestly believe that I _did_ understand, and could reasonably judge. On the other hand, after several years of industry experience, I have rarely seen code which conforms to the level of design and documentation which I required of students completing CS1. (And uniformly _got_, with _no_ exceptions. A great bunch of students. I hope they read this.) >One eye-opening experience is the first time you are called upon to >make an enhancement to a significant program that doesn't follow these >"aribtrary" rules, for instance is well-designed and structured, but >completely undocumented. I agree with the original poster, that the >effect is significantly enhanced when it is one's own code (and one's >own code, a year or two old, may as well be that of a stranger). Yes but: Having worked with both, I'd far sooner inherit code that is well-designed and structured, hopefully with mnemonic names, but without documention, than vice versa. Unfortunately, you almost always get poorly designed programs with no documentation. >A pet peeve of mine is the observation that while textual coding style >seems to be well-established, i.e. CS programs seem to be producing >programmers who consistently indent their code and generally adhere to >consistent conventions (to the point of religious fervor, probably due >to the sort of ritual enforcement I mentioned), there is very little >consistency (or general presense) of documentation. It's probably >easier to enforce and motivate indentation, and I'm all for it, but >you can always mechanically reformat a program; there's no way you can >deduce what it's intended to do (as opposed, for instance, to what >it does :-). Amen. I had the interesting experience, that as a freshman in a CS major, we were not allowed to use the Pascal beautifier, but were forced to meticulously line up our BEGINS and ENDs and our THENs and ELSEs, in a manner akin to preparation for a military inspection. Sadism. -- Lyle sendmail.cf under construction, pardon the From: lws@comm.wang.com (or, uunet!comm.wang.com!lws) (508) 967-2322