Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ncar!gatech!usenet.ins.cwru.edu!usenet.INS.CWRU.Edu!glenn From: glenn@curie.ces.cwru.edu (Glenn Crocker) Newsgroups: comp.org.acm Subject: Re: HS Contests.... Message-ID: Date: 2 May 91 22:19:13 GMT References: <91122.084729TAINT021@ysub.ysu.edu> <9105021917.AA27597@enuxha.eas.asu.edu> Sender: news@usenet.ins.cwru.edu Organization: Case Western Reserve University Lines: 76 In-Reply-To: hurwitz@ENUXHA.EAS.ASU.EDU's message of 2 May 91 19:17:23 GMT Nntp-Posting-Host: curie.ces.cwru.edu hurwitz@ENUXHA.EAS.ASU.EDU (Roger A. Hurwitz) writes: In order to move beyond the current "hacker" mentality ... The hacker mentality is a Good Thing, IMHO. The ACM Student Software Development Contest. The basic idea is as follows: 1) individual contestants are put randomly together into teams, I'm not so sure about this one. Having been involved in several contests, I think that the team spirit involved is good to have. 2) each team is divided into two groups, implementation and maintenance, This is a cool idea. 6) at the end of the implementation phase, each team is given a revised set of specifications reflecting user requested changes, "fixes" to the original specification and other changes typical to the maintenance phase of any software project, I think there should be an intermediate phase in which the maintenance group examines the implementation group's results and corrects them where needed, but that's a minor point. (In actual practice, the maint group would likely split up and have some members examine the current code and some members read the new spec.) 7) the maintenance group of each team is then responsible for implementing the changes to the *existing* program *without* any assistance from the implementation group, and within a fixed period of time, :^) Ok. This is cool too. 8) at the end of the maintenance phase each team is judged on their programs conformance with the specs, as well as on such things as module cohesiveness and coupling (if we can expect high school students to traverse a binary tree we can expect them to understand fundamental notions of good programming!). Time to completion by the maintenance group can also be a criterion, since a fast maintenance cycle often reflects well on the implementors. Judging on conformance to spec is good, but establishing a point system for same is tricky. ("Well, they screwed this part of the spec up, but got this part right. This other group did the opposite. Which is better?") If you can provide objective standards for cohesiveness and coupling, then there is no problem. You can't, IMHO, so this is the weak point of your idea, IMHO. Also, you've brought time back into the scoring system, which I thought you were trying to get away from. I can hack something to match spec.... ... Poorly commented, loosely structured implementations will fall apart in the hands of the maintenance group. This is the best aspect of your idea, IMHO. I also believe that contestants will get valuable team work experience from this approach. By randomly assigning teams, the contestants will get a real feel for the world of software development! In addition, maybe they will make some new friends in the process =). Real software development teams work together for longer than a day. -- Glenn Crocker | Your milage may vary. glenn@ces.cwru.edu | Light bar not for occupant protection. CWRU, Cleveland, OH | Don't drive on frozen lakes. W (216)368-6133 H (216)754-1314 | Do not taunt Happy Fun Ball.