This is a report to the Undergraduate Curriculum Committee of the Dept. of Computer Science on a meeting that I held with several upper-division CS majors.
The purpose of the meeting was to assess our undergraduate degree program from the viewpoint of current students. The students were volunteers from COP4020, one of our capstone courses. These students have already taken most of the other courses required for the CS major, so they have a good perspective the program, including the articulations between courses. I asked Betty Stanton whether this group of students might be biased, toward views of just the strongest students. Her impression was that the list included a fair representation of both "A" and "B" students.
I assured the students that my report to the department would not identify anyone by name, so that they could feel safe in expressing their views forthrightly. The open structure of the meeting allowed students to express views on any subject, and to express opposing views.
I was impressed by the collective knowledge and wisdom of the group, and believe the Department should seriously consider what they have said. At the same time, the group was self-selected (volunteers), and so many not represent all of the students.
The following is an enumeration of the issues that the students raised during the meeting, which lasted over two hours. It is based on my memory and the notes I took during the meeting. The views attributed to students reflect a consensus of the students attending, unless noted to the contrary. My own reflections and recommendations to the department are distinguished from the student input by Italic font.
The discrete math sequence, especially Discrete Mathematics II (MAD 3105), is not working.
I proposed for discussion the idea of replacing Discrete Math II by an introductory course in design and analysis of algorithms, taught by computer science faculty. Since the course would need to include explicit instruction in any mathematics it uses above DM I, it could not move as fast as the current COP4531, and so there still would be material left to be covered in COP4531. COP4531 would also move at a slower pace, since any new mathematics would need to be derived in context, but there ought still be room for COP4531 to go into the principles of design and analysis of algorithms in more depth.
The students seemed to like this idea. Unfortunately, it would have the same coordination problem we seem to have with all cumulative multi-course sequences (see Item 2 below).
The above change might allow us to solve a problem with COP4530, regarding tension between analysis of algorithms content and programming content (see Item 3 below).
I don't recommend extending this idea to DM I, because: (1) there are enough students taking that course that Mathematics is offering it both Fall and Spring; (2) we don't yet know how this merging is going to work out; (3) we don't have enough faculty members to take on two additional courses; (4) we do want the students to see a mathematician's view of proof techniques, logic, set theory, etc.
However there remains a problem, mentioned further below, that DM I is one of the places that we are turning a way a lot of potential CS majors. That is, these are students who might be able to do the discrete mathematics, but decide against the major because they have to climb this mountain (without seeing why) before they are allowed to see enough of the other side of CS to hook them in.
We have a problem with dependent course pairs, including pairs within longer prerequisite sequences like COP3014/COP3330, COP3330/COP4530, COP4530/COP4531. Some terms the problem is repetition, and sometimes the problem is a gap, i.e., something is assumed in a later course that is not covered in the prerequisite. There needs to be better coordination between the instructors, across course boundaries, and more consistency between offerings by different instructors.
These problems are aggravated if a student leaves a gap of a semester or more between taking a prerequisite and the next course. This problem is aggravated in some cases by courses not being offered in the term the course should logically be taken.
There were also reports of bad advice in this regard, overlapping with some other advising complaints (Item 4 below).
I don't see how to resolve this completely, especially in the case of the 4-semester chains. However, we ought to be able to reduce the problem for most students by improving coordination between certain targeted pairs. Techniques we should consider include: (1) scheduling them in Fall-Spring pairs; (2) having a single instructor follow a group of student through a pair of courses; (3) using single textbook for the pair, where that makes sense; (4) establishing a single "owner" for each course or course pair.
Having one person follow batch of student through both courses of a pair seems absolutely necessary with Software Engineering I and SE II, due to the two-term project. I suggest we also consider it CDA3100-3101 (Computer Organization I-II), where there were specific complaints. If we create a new 2-semester algorithm analysis sequence we should consider doing it there, also, or we will end up just swapping one problem for another.
If we cannot have a single instructor cover the entire pair, I think that for consistency and coordination we should establish a single faculty member as "owner" of each course. That should be the person who normally teaches the course. That person should take the time to work with the owners of closely related courses, to ensure that the courses stay coordinated. Keeping one person on a course for several years also enables that person to work on improving the course, rather than chewing up time continually preparing for different courses from one term to another. If anyone other than the owner of a courses teaches it, they should be expected follow as nearly as possible exactly what the owner has specified, down to the lecture notes, assignments, exams, etc.
COP4530 has not been taught consistently. Some students felt they did not get adequate exposure to the C++ Standard Template Library. Some reported a tension between learning how to implement data structures and learning how to use the standard repertoire of DS available in libraries. Students who took the course recently with Ashok seemed to think that version stuck a good balance, between these two. But other students did not.
In a parallel track, I have heard from Sara Stoecklin that she things we ought to be teaching not only generic programming with templates, as exhibited in the C++ STL, but also programming patterns in this course. The students did not comment on this, perhaps because they don't yet know about programming with patterns. However, if we were to move some of the theory from COP4530 into a replacement for Discrete Math II, we might free up some more time for advanced programming concepts and techniques in COP4530.
Some students complained about bad advice. In some cases the bad advice came from our two erstwhile lower-division advisors (Sara and Courtney). In at least one case, the problem was due to transferring to FSU. The specific problems included:
This problem has been solved, in part, by loss of the satellite advisor provided to us by Undergraduate Studies. Betty Stanton seems to be giving correct advice. There seem to remain problem if a student does not come to Betty early enough, because the decision to major in CS is made late, or the student transfers in.
There were some complaints about specific instructors who did not do a good job of teaching a course. Without naming the instructors and courses, the following patterns emerged:
Abuse of power-point or pre-written projected materials in class, as compared to hand writing as the lecture progresses. Students felt that these visual aids were being used to rush through material faster than students could absorb it, and that in some cases it seemed as if the instructor were effectively just reading from the slides. There were also complaints of cases where the instructor may have gone into more detail than the slides, but the presentation was too fast; so, as student who could not follow fast enough in class (or did not have a good oral memory) did not have enough in the notes to be able to go back later and reconstruct what the instructor said. There seemed to be a consensus that when an instructor wrote things down while talking the pace is better. Some students did like having on-line notes, for reference. Some believed the process of writing their own notes during the lecture helped them learn. One suggested using a tool like "Camtasia" (about $300 from techsmith.com) to record synchronized sound and lecture notes, so that students could replay lectures, and distance offerings would be improved.
This is consistent with what I have heard personally from students in the past, and with a teaching workshop I once attended. From the student comments, some faculty members are worse offenders than others. It would be good for all of our faculty to think hard about whether they can improve their teaching in this regard.The Camtasia idea hit a spark for me with regard to the distance learning program, which has presented problems for us, with regard to updating distance learning materials and motivating on-campus faculty members to take on distance learning sections. At the same time, I think it could improve the quality of instruction for on-campus students as well as distance. Therefore, I would suggest the department consider ways of encouraging any instructor who is interested in doing this to do so. However, I would warn against providing any "appreciable support" in the development, so that the instructors can maintain ownership of the recordings of her/his lectures. I believe this could make the instructor eligible for royalties, if the recorded lectures are used by another instructor for distance learning, or the instructor might like to earn extra pay for handling a distance learning section as a teaching overload.
I asked what we can do to reverse the decline in CS majors. The consensus was that they are discouraged and drop in Discrete Math and/or COP 3014.
The students felt if we need to force majors to take Discrete Math I early, then we should either integrate it into other courses (like Discrete Math II), or at least have it taught by a CS professor who will take the time to motivate it.
Regarding COP3014, there were mixed comments about whether it should change. The students in the group had all done well in it, but did feel that it "weeded out" a lot of students who might have been able to stay if it had succeeded in imparting more of the joys of computing to them. Some felt that we need more interesting applications in that courses, perhaps with interaction and graphics.
The students felt we need to do a better job of exposing students to the use of an Integrated Development Environment, since many of them will be using such a tool when the graduate. They did not think we should do this in place of command-line programming, but alongside. They said that the exposure to the MS Visual Studio environment in COP3014, and then switch to command line for everything after, is wrong because COP3014 is not doing anything advanced enough to show the strengths of an IDE. Specifically, they complained that the "visual" part of the MS Visual Studio was never exploited. They proposed running parallel threads using IDE and command line through the sequence COP3104 and COP3330. I asked which IDE, e.g., MS Visual Studio, or Eclipse. The consensus was that it did not matter much which, since a person who is familiar with one can pick up another fairly quickly. They seemed to conclude that Eclipse would be better, because it supports multiple languages.
I wondered whether we might exploit the visual aspect of MS visual studio (and perhaps the Web-support aspects of Dot-Net?) to make COP3014 a bit "sexier", then switch to Eclipse in COP3330.
There was a complaint that we don't regularly expose students to the event-driven programming model, which is the basis of interactive mouse- and web-based applications. There seemed to be some exposure in the C#/DotNet class, but that has not been offered regularly, and is not taken by all students.
There was a related complaint about programming language electives, i.e., that there are no real choices. Besides the infrequency of the C# course, the lack of courses in scripting languages was mentioned.
It seems we should offer C# regularly, but we might also look into whether we can include an event-driven program in COP3014 and/or COP3330. As part of solving the overlap problem of Introduction to Unix and Unix Tools, we might consider making a scripting language a regular part of the latter course, and then counting this as satisfying the second-language requirement.
There was general dissatisfaction with the CS electives. This seemed to focus on the following areas, besides the language one above.
Several of the existing electives were viewed as lacking in meat, and so not worth the time of taking them. Specific examples included System Administration, Unix Tools (with some exceptions, apparently depending on instructor), and Security.
I've heard the same thing on other occasions. We ought to look at beefing up these courses.
A student suggested, with support from the rest, that the department should hold some kind of ballot or poll to gauge the student demand for specific elective courses, and then offer the course(s) that are in most demand for a given term.
It seems to me that is would benefit the department as well as the students, by getting more enrollment in the courses we do offer and so eliminated the problem of offering a course that does not "make". However, when I explained to the students that teaching assignments are done about a year in advance I got the impression that they were thinking in terms of just one semester in advance. We briefly discussed the possibility of a group of students taking initiative by getting together petition of students who agree to take a given course if it is offered.
We ought to allow students more real choice of electives, by reducing the number of CS electives that we require. Some students felt that with us now requiring CIS4250 (Ethics and CS) instead of SPC2600, and especially if we require a CS course instead of Discrete Math II, we ought to be able to reduce the number of electives that are required to be in CS.
This at first seemed like a reasonable request to me, but I don't know how far we can go without running into trouble with our ABET accreditation and SMALC requirements. We might consider making some present required courses into electives, but which one(s)?
The department is perceived as putting more priority on graduate education than undergraduate education, and offering more graduate electives than undergraduate electives. One student commented that it seemed the faculty are only interested in undergraduate students as potential recruits for graduate school. I pointed out the cases of dual-listed graduate courses, which an undergraduate can take also, but was reminded that these generally have prerequisites that few undergraduates can satisfy.
I think this has some truth to it, as regards the perception of faculty priorities. However, the perception on graduate electives is somewhat skewed by the fact that there are very few required graduate courses, so it is natural that most graduate courses are "electives". I think the faculty members need to be come more aware of the impression they are giving to undergraduate students, and amend their behavior.
There was a comment specific to the CDA3100-CDA3101 sequence, that there is too much overlap, at the same time as the content of CDA3100 has varied a lot between instructors. One comment was "half the class is repeated". Most student felt that CDA3100 was a waste of time. Some commented that the final programming assignment (an instruction-level simulator) in CDA3100 one term was essentially the same as that in CDA3101 the following term, to the point that a student could just make a few changes and turn in the same program. The possibility of beefing up CDA3101 was suggested, specifically adding an FPGA programming assignment. Another alternative discussed was re-combining the two courses in order make room for more electives.
I got the impression that the problems reported by the students have varied with the professor teaching CDA3100, and the "waste of time" comment may no longer be true, but that as CDA3100 has improved the degree of overlap with CDA3101 has grown. Not so long ago, we only required one course in computer organization, and it was somewhere between the two present courses in coverage. Perhaps this split is not working, and we should reconsider it. Both possibility suggested by the students seem reasonable. That is, we could upgrade the first course, and require only that of all students, then make the second course an elective. Whether or not we do this, it seems we should upgrade the second course, to reduce overlap, perhaps using the FPGA programming idea.
There was a complaint specific to COP4720 Databases, that the instructor expects students to use Java in the course. Students felt that this is inequitable, since some students have taken the Java course before this class, while others must struggle to learn enough Java to do the assignments in the course.
I see the inequity. I also see that if a student learns Java in COP4710 it is duplicative to ask the student to take a separate course in Java after. I don't see how to solve this.
There was a comment specific to COT4420, that the notes (originally done by Levitz for use in class as well as for distance reading) are good, but that they need updating. The observation was made that the professor commented in class to students on some of the problems, but did not correct those problems from one term to the next.
This one seems easy to solve. The notes should be updated. I subsequently spoke with Levitz, who said he has been working updating the notes. However, he is retired, so it is unfair to expect much of him. Other instructors will need to start lending a hand.
A specific complaint was made about the 1-hr Introduction to Unix and the 3-hr Unix Tools courses. What is covered in these courses varies a lot from one instructor to another, and some cases the courses overlap to a point that one seems to be a waste of time.
This is one of several cases where we have pairs of related courses. We need to coordinate what is taught in these courses better, both between instructors for a single course, and between the two courses.
There was a complaint that some of the professors show up for the first class and don't know how to use the A/V equipment in the classroom. The suggestion was that the professor make an effort to familiarize him/herself with the classroom before the first class.
There was a suggestion that we are not making good use of recitation meetings. Recitations should not amount to just another lecture (perhaps by the TA instead of the professor). There seemed to be consensus that recitations are good if they are used to help students get started or get over humps in a regular programming assignment, by programming on it with a person (TA) present to answer questions. However, the idea of having recitation-specific assignments, that must be completed by the end of the recitation was criticized, was viewed as transforming recitations from being helpful and encouraging to being intimidating and discouraging.
This does seem like one of the kinds of things we should be doing in recitations, along with other activities that require more instructor/TA attention than can be given in class or by e-mail.
Minutes by Ted Baker, UGCC chair