Redesigning a CS Curriculum
A number of my posts over the last couple of weeks have concerned education and curriculum. I met with a couple of the educators here at UCI, to go over these points. I’d like to record these thoughts before they evaporate from my brain.
The primary elements of a CS education:
- In class code reviews.
Similar to what I repeated about the Japanese techniques, this technique gives all students the opportunity to see what approaches their peers are trying. American culture is such that, we’d have to be careful as educators to anonymize any code or designs shown (or take samples from a previous offering of the course), so that no students are emotionally compromised. For a field such as CS, where abstract reasoning, and design issues are paramount, the exposure to different approaches, and analytic discussion of rules of thumb are vital. - Counseling.
In order to prevent students from having too bad of an experience, or from developing a distaste for the field, we need to ensure that we can catch them before they start failing. It is important to catch those students who start falling behind the rest of the class as early as possible, before they become unable to catch up (or keep up). We need to let them know that repeating a class is not the end of the world, and is better than getting a C (or worse) in all later classes that depend on mastery of material. We need, also, to let our students know the overall design of the curriculum, so that they can see where each class fits into the goals of the degree. We should also expect that the student body is aware of classes/workshops that help to improve study/work habits, and any learning assistance available. - Dependency Graph.
In order to ensure that all essential topics are discussed, and all material that later courses depend on, are actually presented (and exercised) in earlier courses, we must have a dependency graph of the pre-requisites for each course. At UCI, the CS major is related (and shares classes with) at least 8 other majors, so this graph is not necessarily easy to produce. However, it will enable students to know at what point they can switch majors (say because they realized they enjoy human computer interaction, or would rather focus on algorithm analysis, etc). It will also enable counselors to show, pictorially, where each class fits in each degree. - Standards.
Each class needs to ensure that it only passes students with the specified abilities. This ensures their success in later classes, and ensures that they acquire all the skills they need for the later, more specialized and demanding classes. These standards can also be used to allow students who already have the skills (analytic/programming skill, if not inter-personal skills) to test out of a course, and not get held back (becoming bored and surly). To keep these standards from slipping, the consumer (that is, instructors of later courses, as given by the dependency graph) must hold each of the earlier classes accountable for specific student abilities. Standards will also ensure that poor performers are identified early, and receive proper counseling. - Participation.
We need to ensure that students are engaged with the material. Projects in each class should be conducted in as interactive a manner as can be managed. Material covered should be presented in a variety of ways so as to capture the attention of each different type of learner. The XP methodology, and in-class discussions help considerably in this regard. How far this is taken can be a matter of debate. - Continuous Measurement.
In order to improve any established curriculum we need to track which students from which majors do well on which topics in which classes. Such statistics can be done with anonymized data, but are necessary to ensure that the program can correct to changing demands and circumstances of the field. We also need to ensure that, for each major, all the necessary topics are discussed in enough detail before a student can graduate. However, actually measuring this performance, is necessary for evidence-based course modifications, rather than personal whim or anecdotal experience of committee members.
Although, all of these are very important for designing a curriculum, I’m most interested in how it plays out for the compilers class. I think we need to ensure that all paths that students may use to get into the class hit all the required design patterns, so that students are not set up to fail. Even if this exposure is spread across many courses, we should be able (using the dependency graph) to ensure that each topic is presented, and (using performance metrics or assessment tests) that each student has the required understanding.