Many of the exercises in this course are concerned with reinventing the wheel. Writing your own text editor program, when you already have several on your computer, and hundreds of other people have already written their own and make the program source freely availeble on the web for you to copy..
Educationalists will have their own answers to this as part of the learning process, but in the world of computers several problems arise when asking a student to write a program as home work. Most likely this program has been writtin a 100 times already and is already available on the net. The student can just find and download the program, check that it works and the home work is done. Teachers no longer have the control over students access to teaching texts that they used to have when schools issued schoolbooks to classes. Huge copies of material can be copied at the press of a button. Either work from previous years and classes or from classmates. Classmates can even swap homework on-line as they are doing it.
Within the world of computers there is nothing to be gained by reinventing the wheel. Such exercises should be kept to simple short tasks which basically help the student get started. They should be highly structured and tightly monitored, for instance, done only within the classroom.
Rather than reinvent the wheel, efforts should be made to find new problems, variations, new ways of doing things, developing conforming behaviours on programs, creating new extensions, new ways of communicating, and of getting students to also do these things. Opportunities in this regard have never been so vast nor the means to travel into new territory so easy. Now it is much easier to get students to work together on projects, to swap ideas and solutions and this process of cooperation can be reinforced. This is a good social glue and is an antidote to the values of personal intellectual eliteism that can develop from the comptetitive assessment paradigm.
Despite the large amount of software available, there are many existing solutions which students may find awkward to use and want to redesign into a better more accessible product. Examples of this type are included in this course.
One way to design exercises to minimise the risk of copying is to specify the exercise in a way that is not the way that it might normally be done in a fully fledged product. As an example, in the Text Editor and later in the OOP exercise based on the text editor, the File Save and Open functions are specified as buttons in a menu bar. In most production programs the 4 functions would be placed in a menu list under a single menu button. But in these exercises the menu buttons are used because they are a simpler more accessible function to learn and they do the job under the circumstances in a slightly non standard (maybe primitive) way. This means that a student cannot just pick up an existing solution and cut it down to fit the exercise, thought he might learn a lot by using this process.
While copying the work of others may be the bane of the classroom assignment teaching process, it is in fact how computer programs are developed. Reusing existing code is the most important and powerful way to develop new applications. Learning how to generalise functions, encapsulate behaviour, combine existing functions in new ways, these are the topics of most importance in the Advanced Section of this course.
The exercises most likely to be copied are the ones that involve a lot of work. For computer programming exercises, copying various components and assembling them to provide the completed product is a perfectly valid technique. The way to ensure that the project is not copied verbatim is to always split the exercise into Specification, Design, Implementation and Test phases.
Specification - The teacher issues a brief specification of functions to be included. The idea here is that the assignment include the specified functions but no more. If the teacher asks for a limited function program and the student produces a fully fledged product he effectively fails the assignment. It is a key aspect of programming that a program do no more than it is required to do. This is an important aspect because many computer projects have failed or blown their budget because they have exceeded their initial specification and lost sight of the basic goals of the product. But in the teaching situation an overblown product is more likely to result from copying an existing product. A teacher may be concerned that students will take a full-featured product and cut it down to size to meet the requirements of the exercise. While this is cheating in a way, it is actually not so easy to do in practice, and the student would probably learn so much about the product he was tampering with that he would satisfy the goals of the exercise anyway. Again, lifting routines, methods, ideas, structures and algorithms from existing programs is all good practice. Often the student will discover that existing methods are not so good and will find a better way that will benefit everyone.
Design - The students write their own design in the form of the help documentation for the product. This becomes an integral part of the final product and is not thrown away. It is also used to assess the exercise - to see if the program does what it is intended to do. The specificiation can be assessed on its clarity and detail and completeness before implementation begins. It should also be assessed on its constructive approach. That is: does it describe the program features in a way that allows you to use it creatively. The opposite of this is a bald description of the functional features (a feature typical of Microsoft software) with no reference on how to use features in combination or sequence to achieve creative goals.
Implementation - Within this framework, lifting of existing solutions ceases to be an assessment issue. But marks could be assigned to innovative technical solutions.
Testing - Various methods can be used for testing. Testing involves a number of aspects. Firstly and most obvious is that the program works. But often this as seen as the only requirement. Possibly a more important criterion is whether the program is readily used by its target audience. Another issue is whetherthe program is resilient to misuse. The program should not permit interactions to occur which cause to it malfunction. The design and implementation should eliminate opportunities for malfunction.