Path: utzoo!attcan!uunet!ogicse!ucsd!ucsdhub!hp-sdd!apollo!perry From: perry@apollo.HP.COM (Jim Perry) Newsgroups: comp.edu Subject: Re: Software Engineering/Group Projects Message-ID: <4949e7d2.20b6d@apollo.HP.COM> Date: 19 Mar 90 15:19:00 GMT References: <1175@dftsrv.gsfc.nasa.gov> <210@samna.UUCP> Sender: root@apollo.HP.COM Reply-To: perry@apollo.HP.COM (Jim Perry) Organization: Hewlett-Packard Company, Apollo Division; Chelmsford, MA Lines: 72 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.