A curricula for teaching computer programming / software development


A lot of my posts tend to focus on new technologies and looking at how those could impact education and instructional design. But I’m going to switch gears for a bit today with a draft idea for a teaching plan for the classroom. This idea is for a curriculum of projects in a high school enriched or CEGEP/junior college level class on computer science and teaching computer programming.

Motivation behind this article

I’ve recently been enjoying a MOOC course that I’m taking from Rice University through Coursera. The course is an Introduction to Interaction-Programming in Python. It’s great. Mix of teachers gives a variety of styles of presentation. I’ve  come to realize more how important it is to give instructors in MOOC course the creative room to express their personality for their buy-in to the approach.

The course is nine weeks and has a nice project based approach where each week there is a new project. The projects start out simple and get more sophisticated as the weeks go by. The final project is a simple space shooter video game.


Anyhow, the material taught and the project based approach got me to thinking about how introductory computer science is taught and gave me the idea for an approach to teaching computer programming in the advanced high school or junior college classroom. (I took such a course myself in high school, and it was one of the more influential I took during that time period)

A note about programming / software development

Although computer science types are often stereo-typecast as loners without social skills, the reality is that modern software development is a highly social field. The largest software projects could not be completed in any reasonable amount of time by one individual, in some cases probably even in a lifetime. Tens, or at the high end, even hundreds or thousands of programmers can work together on one project. They need to communicate, coordinate, divide tasks/delegate, and collaborate. These are key team skills. Not to mention skills of decision-making and conflict resolution.

The open source programming movement is another good example where the emphasis is on sharing and collaboration.

The Course Design

Make the class be based on projects, with the project being some sort of computer program. The projects would be chosen so as to require larger sorts of programs to complete. Each will take hundreds of lines of code of complete. One of these every two weeks say. Would be cool too, ideally if each of these biweekly projects contributed to one large end of term project. That would take significantly more effort for the teacher to plan though. Should be one larger term project though, also collaborative.

These projects would be collaborative, built in groups. Divide the class into 3-4 groups, depending on class size. Want 6-8 students in each group.

The first few weeks could give some basic orientation, the chance for the class to read the first couple of chapters of the text, and go through some basic individual exercises. You can get some idea from this about who are the keeners and potential leaders, both for projects and for project sub-groups.

Once the class is ready, a few people could volunteer to be the main architect/lead developers for the program for each group or the teacher could assign. These leads could select say another one or two students to help design the higher level structure of the program. The teacher would support as needed. Those students would be able to get the highest potential mark, say an A+ or 100% because the task requires higher level thinking and work, and also because that’s the position that would get paid better in the real world. Then the other students in the team can be assigned to or choose different sections of the code. Those sections would be worth different amounts, based on the complexity of the task. One chunk or task might give a max of 85%, another 70% say.

Everyone can get something that gives them a solid pass.

Opposing teams test each other’s compiled executables (group # 1 grades 2, 2 grades 3, 3 grades 4, 4 grades 1, e.g.), trying to find bugs and writing bug reports. The teacher would show them how to perform bug testing and some templates for writing bug reports.They hand these back to the development group and give one chance to fix it. If this step is required, maybe the whole group gets reduced by a flat 5% for simplicity, whether one bug or many. (Aim for zero errors)

The team then verifies and tries to fix the bugs within a certain time window and then sends it for the second review. If the development group can’t reproduce the documented bugs, the team can appeal to the teacher, who will also investigate and cancel the deduction if he also can’t reproduce it. It is put through another full test again at this point. Bugs that remain are documented and a sliding grade reduction applies to the development team members based on what remains. (Not just the original bugs are tested – sometimes fixing the bug causes new bugs, so a full additional test is needed.)

The teacher calculates the grade based on this peer review. The peer review encourages teams to compete against each other in developing testing skills. The teacher makes his own review, and factors this into the grade as well. After each project, once evaluations are done, the teacher will take a class to review each teams projects together as a class, to discuss lessons learned.

Group leaders / architects need to develop testing routines based on reading and teaching from the text and the teacher and need to make sure others in the group apply testing on their own work to avoid losing marks.

The groups would not be permanent over the year, but would be picked anew for each project. Even the team leads might change as someone else within the groups shows an elevation in skills to a new level and the instructor and/or class feels he deserves a chance to try leadership. The teacher should instill values in those who regularly are team leads/project architects that it is important for leaders to step aside enough to give team members a chance to grow and shine.

Challenges: points still to resolve

The instructor would need to find a system to decide how the errors made by individual team members in their portion of the project affect the grade of everyone else. On the one hand you want to encourage the team leaders’ management skills development and the whole team’s teamwork skills. At the same time you want to prevent anyone from freeloading off the others in the knowledge the better students will do it for him out of concern for their own marks. (As is often a problem in group efforts, in school and in the workplace) Part of an individual’s mistake would reflect on the group, and part would be his own deduction.

Foreseeable critiques

One critique I would expect from educational circles would be that the competition and team rivalry aspect might be discouraging or off-putting to girls, who are already under-represented in the computer science classroom. On the other hand, the emphasis on the collaborative aspect of software development with it’s aspects of precise and effective communication, coordination, and collaboration might actually make things more attractive to the girls.

As well, the competitive aspect can be kept to relatively safe stakes. The instructor can emphasize that the focus in grading is on the objective absolute quality of the work each team does and not the ranking between the groups on a project. The recognition or honors given by the teacher are not an all or nothing thing lavished on the winning team each time. The lessons learned discussions post project also allow some of that essential soft skills aspect to come to the front.

Arguably, this approach actually brings out a balance in hard vs soft skills much better than the usual methods, and may be the sort of mix that is attractive to both genders.

Possible Modifications

One possible modification of this that I could think of that would subtly shift the tone would be to have the different teams collaborate rather than compete. Each group would get a different, but comparably difficult sub-task for implementing one overall programming task. This would require more time from the teacher to plan and coordinate all this, to think up a proper sized overall project and to evaluate multiple tasks rather than each group doing the same thing. The teacher would also probably have to take on the role of project architect, making the basic overall plan and structure and delegating well-defined but demanding sub-programs to develop to each group and monitoring what they are doing and that it fits in with everything else.

The other wrinkle is that ostensibly the different teams’ programs / modules would need to interact with the other teams’ modules to function. This could complicate testing.

Perhaps the best way would be for an instructor to try the competitive approach first a few times, and when he feels comfortable with it, then try the course collaboratively.