Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!cs.utexas.edu!uunet!fernwood!uupsi!ficc!peter
From: peter@ficc.ferranti.com (Peter da Silva)
Newsgroups: comp.org.acm
Subject: Re: HS Contests....
Message-ID: <6A1BO34@xds13.ferranti.com>
Date: 3 May 91 16:01:49 GMT
References: <91122.084729TAINT021@ysub.ysu.edu> <9105021917.AA27597@enuxha.eas.asu.edu>
Reply-To: peter@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 28

In article <9105021917.AA27597@enuxha.eas.asu.edu> hurwitz@enuxha.eas.asu.edu (Roger A. Hurwitz) writes:
>     1) individual contestants are put randomly together into teams,
>     2) each team is divided into two groups, implementation and
>        maintenance,
...

I've been watching these ideas go past, thinking "no way are you going to
solve this problem in a contest environment". It's just too subjective! But
this is a perfectly workable solution, modelling the real world fairly well.

You can run changes on this: put everyone on implementation, then when it's
finishes switch the teams around and have everyone do maintainance. This way
everyone gets to work at both sides, and everyone gets two scores. Give
separate prizes for implementation and maintainance, and a separate grand
prize for the best total score. If there's enough time, switch them around
again for later changes or even give them the original code back to work
on some more (ideally, this last part should be 6 months after the original
contest completed :->).

>     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

I'm not sure you can do this last part objectively. Otherwise it's a great
idea.
-- 
Peter da Silva.  `-_-'  peter@ferranti.com
+1 713 274 5180.  'U`  "Have you hugged your wolf today?"