🚀 go-pugleaf

In article <9105020134.AA29577@enuxha.eas.asu.edu>
   hurwitz@ENUXHA.EAS.ASU.EDU (Roger A. Hurwitz) writes:
> At the risk of getting char-broiled, it is my belief that the entire
> idea of programming contest that puts a premium on speed rather than
> quality sends the wrong message to CS noviates.  [...] Why not make
> these things software design contests, and judge the contestants on the
> quality of their designs?

As a veteran of a few years of these contests - both as organizer and
competitor, high school and collegiate level - I heartily agree.  The
current approach is to solve n problems in time t or better -- with no
regard to style of user interface (unless specified in problem),
modularity of design, efficiency of code, etc.

However, in organizing high school contests at Merrimack College,
every year this discussion came up, and every year we got stuck on the
fact that judging "good" and "clean" code is *wildly* subjective.  We
tried an approach where teams we be awarded "extra" points, above and
beyond a time-based score, for "good" code but the judges (the
department profs :-) had different ideas as to what programs were
"good".  Bzzzt.  And in any case, a smart time would blow off the
quality points and strive for raw speed to complete problems, unless
the quality points were weighted heavily enough.

Given that programming contests are good for business in that they
create interest for high schoolers and keep college kids busy (half
grin), here's the deal.  Along the lines of what Roger posted, why not
bag the whole n problems in time t idea and go for 1 (one) problem:

Outline one largish program - to use an infamous Merrimack College
example, call it "Joe's Sub Shop": the program will, say, use queues
to schedule arriving customers, have an ordering scheme to create
subs, have an elaborate cost-figuring scheme ("pickles $0.25 extra,
unless it's a large in which case pickles are free if it's not whole
wheat bread"), keep statistics as to how many of each type sub
ordered, etc etc.  Give them the problem by outlining the required
tasks, and let 'em go to.

This will encourage all team members to work together on one problem -
something not much done now - as well as make them write modular code
(n terminals for n team members might be nice).  We can't be too
advanced - these are high school kids - but you get the idea.

The teams will have to design and implement the program in one day.
At the end, the programs are reviewed - this will take some time - by
several judges independently on modularity, user interface, data
structure usage, etc.  The opinions are tabulated, and the winner is
declared.

Side thought: drum up outside interest by getting a local company to
underwrite cost of refreshments & let 'em provide one of their
programmers to code up a solution and present it to the teams while
the judging is going on at the end of the day.

This idea has some inherent difficulties, admittedly, but I think the
concept is much more sound and more in keeping with modern CS thinking
than current contests.

I'd be interested in other opinions - email or posted.


-[mpg]
 mikeg@lanl.gov
 former Merrimack College ACM Chapter Chief Techo-Geek, now humble grad student