Ducky Ethics Approval Form Draft Notes

Purpose: collect data on how students actually program in an IDE (Eclipse) and explore the data. If we find differences between the logs of high-scoring and low-scoring code development sessions, that could potentially be used to teaching and/or development tools.

Subjects: students in a computer science class which uses Eclipse/Java for individual programming assignments.

Question: which level? 200 or 300 or both? which class?

Needed from subjects: logs of their coding activity for each assignment plus the assignment handed in plus the grade that they got for the assignment.

Also needed: someone to obfuscate identities, so that we don't know who did which assignment.

Question: do we need to obfuscate what code is being modified? I don't think so, tho we probably want them to use Mylar to only give us that assignment's context.

Question: do we want to keep track of which assignments belong to which students, or have each trace/handin/grade tuple be separate?

Possible downsides for the student: slightly slower performance on Eclipse; feeling self-conscious while coding?

Compensation: ?

Possible follow-ons: look at differences between logs of professionals and students; between IDEs; between languages.

Or if the logs say that the mechanics aren't that important, that the thinking is, then maybe diverge into testing thinking ability in various ways and seeing if we can do some remedial thinking training. (?)

Potential harms:

• The monitoring plug-in could make Eclipse crash, causing them to lose work.
• If there is a recognizable difference between traces of good code development and bad code development, companies could use logging to make hire/no-hire decisions and/or performance appraisals. Companies could focus on raw coding development skills (as given by the score of the log) to the exclusion of other useful skills (like documentation, vision, quality of comments, etc).
• Companies could track their coders' work tightly enough to make the coders feel pressured and stressed. Overreliance on coding score could lead coders to "game the system" by altering their interaction patterns even to the detriment of code quality or speed.
• If instrumenting developers' tools proves successful in evaluating coders, this technique could potentially be used in other domains. While very little of a coder's personal life leaves a trace in their code, one can imagine instrumenting email as well, where there is a huge amount of personal information that routinely travels around in email.

Things to watch out for: DUCKY must make the appeal to students, NOT the instructor, and make it clear that the instructor is at most a transport mechanism.

Review: This seems like a minimal harm study, so an annual review is probably fine.

Urk. "Fewest subjects" requirement. Urk. How do we know?