🚀 go-pugleaf

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.