Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!ENUXHA.EAS.ASU.EDU!hurwitz
From: hurwitz@ENUXHA.EAS.ASU.EDU (Roger A. Hurwitz)
Newsgroups: comp.org.acm
Subject: Re: HS Contests....
Message-ID: <9105021917.AA27597@enuxha.eas.asu.edu>
Date: 2 May 91 19:17:23 GMT
References: <91122.084729TAINT021@ysub.ysu.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: hurwitz@enuxha.eas.asu.edu (Roger A. Hurwitz)
Organization: Arizona State Univ, Tempe AZ
Lines: 52

I was pleasantly surprised by the encouraging responses I received on
my criticism of current ACM programming contests.  In a nutshell, I 
(and others) believe that these contests, while encouraging an interest
in computer science, send the wrong message to future practitioners.
That is, current contests reward cleverness and speed at the expense
of quality and discipline.  In order to move beyond the current "hacker"
mentality fostered by these contests without undermining the enthusiasm
they generate, I propose the following alternative:  

            The ACM Student Software Development Contest.

The basic idea is as follows:

    1) individual contestants are put randomly together into teams,
    2) each team is divided into two groups, implementation and
       maintenance,
    3) every team is given the same detailed set of specifications 
       for a simple project,
    4) the implementation group on each team is responsible for 
       implementing the project within a fixed period of time,
    5) the maintenance group cannot participate in the original 
       implementation but may retire elsewhere to study the specifications,
    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,
    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, :^)
    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.
       
I believe that this form of contest encourages good software engineering 
practices because, in effect, contestants will be rewarded for their
ability to write programs that are easily maintainable and understandable
by others.  By isolating implementation from maintenance, the maintenance
group will have to rely on the code itself to complete their task.  Poorly
commented, loosely structured implementations will fall apart in the
hands of the maintenance group.

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 =).

Responses are welcome.