TAINT021@ysub.ysu.edu (David M. Onder) (05/02/91)
I have a response to Roger Hurwitz's comments on the high school contests. We here at this university have chosen to do a small number of contest problems that take the students into a few areas of computer science. Generally, we have questions relating to computations, searching, and string manipulation. All these areas are good tests for high school students, since these students are not too good at software engineering yet. For a college level competition, I would agree to a contest that would judge the quality of the programs, as well as the correctness of the programs. Does anyone else have any comments on this subject. We could all end up having great contests next year if we analyze this completely. BTW, I was supposed to send some contest problems to a few organizations, and I am not sure if I got them all out. If you requested the problems and never got them, please mail me again. I will get them out this time. Thank you!!!! David M. Onder YSU-ASM Student Chapter President YSU-ACM Student Chapter Secretary /-------------------------------------------------------------------\ : "To see the world through my eyes is | asafcm01@ysub.bitnet : : to see very little of the world!" | asafcm01@ysub.ysu.edu : : (Anonymous) | acm@ysumax.macs.ysu.edu : \-------------------------------------------------------------------/
hurwitz@ENUXHA.EAS.ASU.EDU (Roger A. Hurwitz) (05/03/91)
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.glenn@curie.ces.cwru.edu (Glenn Crocker) (05/03/91)
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.thom@ecrc.de (Thom Fruehwirth) (05/03/91)
I like it. I think the graphics are great. Actually I am going to make a poster out of one of the latest title pages... thom
peter@ficc.ferranti.com (Peter da Silva) (05/03/91)
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?"
jeff@crash.cts.com (Jeff Makey) (05/06/91)
In article <9105021917.AA27597@enuxha.eas.asu.edu> hurwitz@enuxha.eas.asu.edu (Roger A. Hurwitz) writes: >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. If the programs are judged by the correctness of their output, I don't see how quality and discipline are being compromised. True, there is zero emphasis on programming style and maintainability, but for small problems of the type that are to be solved in these contests the best thing is just to get the %#@*! program written and be done with it. That's the way the real world works. :: Jeff Makey ACM member since 1980 Department of Tautological Pleonasms and Superfluous Redundancies Department Posting from my temporary home at ... Domain: jeff@crash.cts.com UUCP: nosc!crash!jeff
craig@med.unc.edu (Ron Craig) (05/08/91)
In article <9105021917.AA27597@enuxha.eas.asu.edu> hurwitz@enuxha.eas.asu.edu (Roger A. Hurwitz) writes: >[ ... Statement on evils of rewarding cleverness more than good design deleted > ... ] >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, > [ ... other points deleted ... ] >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 =). Just don't forget to give *individual* trophys/certificates AND a school award to each school having a member on the winning pair of teams. Some schools really allow their students to go so that the school gets an award it can show to local businesses that donate equipment. -- Ron Craig inet- craig@med.unc.edu CB# 8180 - UNC Chapel Hill bitnet- URONCR@UNC.BITNET AT&T- (919) 966-3681 Chapel Hill NC 27599-8180 My opinions are valued by UNC, not shared by them.