The traditional method of programming lessons continues to be giving a whole class a distinct assignment testing their ability to use whatever programming skill they were supposed to be learning that week: make a loop, get input, etc. The students, if they do the work, are left with a folder full of little programs that do nothing particularly useful. In the best case scenario they may refer back to them in the future as examples.
This is based on a sequential method of teaching programming. Hopefully at the end the students will be required to combine those skills into a more significant program, but I suspect that rarely happens. Even at the college level this method often continues, with the focus on learning the syntax of this or that particular language. It’s only the most advanced students that confront real problems with their programming.
There is a reason for that: a program that addresses a real problem will of necessity be long and involve a bunch of different keywords, concepts and procedures that must be learned in advance. It’s not reasonable for a single student to do it. And students who work together won’t have the skills to make their individual parts combine.
What if we, as software teachers, take the leadership role in making the parts of their program together?
As I’m imagining it, each small group of 2-3 students would be assigned a small part of a big program that is meant to address a real-world problem, such as acquiring real-world data and displaying it in an interesting way. They would only need to learn two or three distinct skills to do that. They’d have to practice this skill a few times first, then they’d be given a unit tester program and told the expected outcome.
Unit testers are already used in college classes, but every student gets the same unit test to solve. In this system I’d imagine each group would have to solve a different unit test. The tests would be designed so that each module that could solve it would fit together to make a working program.
Except of course it probably wouldn’t work together at first. Then they’d have to look at what the others did and see where the problem was. If this was done correctly the students would be having regular meetings every few weeks where they shared their progress and what they got working. In the process of collaborating they’d come to understand what the other units were doing.
But then they wouldn’t learn all the skills! you say. No, not at first. They’d learn one skill, and they’d really learn it. They’d have a bit of understanding of what everyone else did. And they’d have a program that really mattered.
I certainly don’t want to add on to the people abusing the word Agile in programming. Maybe I should use another term. But I think this works towards the sense that Dave Thomas intended. The students’ solutions would, at first, only solve the problems in the most trivial way. Then they’d work through harder and harder unit test cases. It would be up to the students at every point to see what’s missing. By sharing their work with other groups and seeing what they are doing they’d have a sense of collaboration. Ideally they themselves would come up with the distinct problems to be solved which would then be divided between groups.
I’ll be honest, I haven’t done this yet. Maybe it won’t work. But this year I am going to try it. I’ll list the outcome on the blog.