Generic Programming and Library Development

Quarter 4, 2007

Course evaluation

The course evaluation was carried out in the form of a structured dialog. Each student was allowed to write at most five (5) comments about the course, including what was good and what was bad. Thereafter, the comments received were circulated around and each student could tick the comments he or she agreed on. The comments that got most marks were then discussed by the students and the teachers (Kenny and Jyrki) in a dialog.

Statistics

Number of students who registered for the course: 42
Number of students who attended the first introductory lecture: 35
Number of students who passed the course: 32
Number of students who showed up at the evaluation meeting: 8

Student feedback

The comments that were discussed at the evaluation meeting are listed below together with the number of marks received.

+ 7: Godt med et kursus der også tager en praktisk tilgang
+ 6: Nyttigt stof i pensum
- 6: Code review kunne have været godt. men lidt spild af tid
+ 6: Godt med lidt programmeringsinfo på højere niveau
- 6: Intro-førelæsninger lidt banale
+ 6: Godt med assignments; De holder en i gang
- 6: Mini-projektet måske en smule for stort
- 5: For stort spring i arbejdstiden i ugeopgaverne
- 5: Jyrki, kommentér din kode!

Future of the course

The same course team (Kenny, Knud, and Jyrki) has now given the course twice. Based on the feedback received last year and that received this year, the students liked the structure, form, and content of the course. 31 students passed the course last year and 32 this year. That is, there seems to be a constant demand for the course. As to the teachers' standpoint, our main motivation for offering the course has been to prepare the students for projects to be done at the graduate level. Much of the research done at the department require that the students (whose education is research-based at the graduate level) know the techniques used in generic programming well (in particular, those used in C++ programming). That is, it is of the interest of the research groups that the course is kept in the curriculum.

It is time to think of the continuity of the course. Even if the course team has consisted of three teachers, during some peak periods the workload has been high mainly because of the weekly assignments and mini-project. It will be most probable that we cannot offer the course in its current form next year. Especially, Kenny and Knud are overloaded because of their other teaching obligations. To be able to offer the course again, either the course team should be renewed (e.g. by replacing Kenny and Knud by some interested Ph.D. students) or some of the money generated by the course should be used for hiring teaching assistants (and let Kenny and Knud only do lecturing).

Majority of the students think that the course should be offered earlier in the curriculum (i.e. moved to undergraduate level). We warmly support the idea of making the course a permanent part of our undergraduate education (e.g. as one of the optional courses offered in the third year). And as said already above, the department must provide teaching assistants for the course to make the teachers' work more attractive. We hope that these issues will be taken up---and solved---by the management team.

Corrective actions

Based on the comments and the dialog, some minor corrective actions will be necessary if the course will be given yet another time. More specifically, we have considered the following issues.

* Up to now, the main focus in the course has been on generic programming as it is offered by the C++ programming language. Already this year in the last lecture, genericity offered by other programming languages (C#, ConceptsC++, D) was briefly discussed. In the future, we cannot ignore the development that is happening in other languages, but should find space to cover that too.

* This year the review assignment was extended to cover the design and documentation, in addition to the code. We also made the process dynamic such that the students were reviewing each other's work (based on a midway report of their mini-project). For some groups (for too many in our opinion) the review assignment was a disappointment. The students disliked the extra paperwork incurred by the assignment (midway report and review report). Also, the review was placed so early that not much code was written at that point (this was the case for many groups). Definitely it was a good idea to base the review for the material produced by the fellow students, but some rethinking will be necessary to make the process more fluent and not to disappoint so many students.

One of the students (Axel) provided us the following proposals what to do and what not to do:

1. Limit the number of deliverables to one (or zero).
2. Keep the review general (instead of focusing on the code alone).
3. Pair the review groups so that they work with the same problem.
4. Move the review earlier or even have two inspection meetings.
5. Present the material on reviews at lectures one week before handing out the assignment.
6. Keep the review process dynamic (i.e. do not go back to review some old code) so that the students can benefit from each other's work in the mini-project.

* The assignments, presentations, and mini-project were made in groups of 1-3 people. In total, there were 15 groups---3 consisted of one person, 7 of two persons, and 5 of three persons. The constellation of all groups was the same throughout the course. We fell that instead of keeping the groups stable, it may be a good idea to force the students to solve some of the exercises with different partners. Now Danish students worked together and Erasmus students together---with no exceptions. Many students would benefit if they had more social contacts to their fellow students. That would improve the social integration of the students.

Thanks!

We are grateful for the feedback we received, and we want to thank those who provided that for us.

July 25th, 2007
Jyrki Katajainen