Additional profile information on Alfred Thompson at Google+
One of the things that computer science teachers all seem to struggle with is coming up with projects to assign their students. I was thinking about this after reading Robb Cutler's latest at the Computer Science Teachers Association blog. OK try and follow my twisted logic. Perhaps it's as interesting (or boring or wierd depending on your point of view) as Scott Adams (of Dilbert fame) writers block post.
Robb was using Sudoku puzzles as an example of problem solving. He was pointing out that the sort of talents and skills that people use to solve those puzzles was exactly the sort of talent and skills that are useful in computer science. He's right of course. The whole pattern matching thing is highly useful in computer science. I was of course somewhat distracted by the thought "how would I write a computer program to solve a Suduko puzzle. That lead directly to how would I assign it to a class and what sort of things would I be using it to reinforce.
For the most part programming projects just sort of came to me. I'm not saying that all the projects I assigned were original. Nothing could be further from the truth. A lot of them came from textbooks. Many came from talks with other teachers. The Nifty Assignments panel is one that I never miss at SIGCSE. The supporting web page for the Nifty Assignments discussion has an archive of projects from past sessions here. I highly recommend that page and the SIGCSE conference itself.
But still some of the best projects I assigned came from (almost) thin air. Discussions with students inspired a number of them. A class discussion about a topic lead to talk about how you would use something which lead to brainstorming about potential projects. More than once we came up with a project on the spur of the moment and it became a assignment. There is good and bad here. The bad is that I, of course, had to go out and write the program myself. There is no sense in assigning a program if a student can not practically finish it in a reasonable time. On occasion this exercise (writing the program myself) showed that there was a concept they needed that they had not been taught or some other thing that made it necessary to modify the project. But the good, and very good it was, that came from these projects is that the students felt some ownership of the project. It was for them and from them. It meant something to them. And that always meant a higher class of work.
So keep an open mind during classroom discussions for potential assignments. Also think about the sorts of puzzles that intrigue you – they may very well intrigue your students as well. One more thing – keep an eye out for students in your school who like puzzles. Maybe you can get them to think about the great puzzle solving business that is computer science.
- Alfred Thompson
One of the things I struggled with as a teacher was getting students to understand the importance of a test plan. Not a plan on how to take a test, although that was a topic that came up with regards to the Advanced Placement Computer Science (APCS) exam. No, rather what students sometimes had trouble grasping was the importance of planning how to test their computer programs.
My good friend Tom Indelicato, who teachers computer science at Bishop Guertin HS, recently wrote about an experience he had with bad test data. Read the whole entry when you get a chance but the short version is this: Tom has been working with a Visual Basic version of a program called ChipWits for a number of years. He acquired a set of instructions for this program, which is something of a computer emulator, and tried them in his version. It didn’t work and he could not figure out what was wrong with his program. Only recently did he find out that the problem was not with his program but with his test data.
In one form or another that is a typical problem for testing software. The test data has to be correct. What does correct mean? Well, that gets complicated at times but my general rule of thumb is that good or correct data has a known outcome. The key thing is that the program should take specific data and return a result that should be known in advance. And of course you should make sure that the program handles “bad data”, what ever that means in the context of the program, and returns a predictable result.
Often is the time I have looked at a student working on a program, watched them enter data and get a result. If the program did not crash they assumed the program worked. Ah, the confidence of youth. So naturally I ask them how they know the answer is correct. About half the time the answer I got was “I don’t know.” Most of the rest of the time the answer I got had something to do with an assumption that the computer was doing the right thing. In short, trust the computer. Now the teachable moment is used to explain a couple of things. One is that it’s not the computer I need to trust but the programmer. The other thing to explain is that assuming something is right is seldom a good idea.
For many projects I assigned I would supply test data. In some cases this makes sense. For example one of the first, if not the first, programs I used to assign was a temperature conversion program. At that point in the course the students had few programming skills and very little idea about testing. So I would explain the test data and why I picked it. I always used three data points: freezing, boiling and -40. I would explain that I picked those values because I knew what results I would get without having to do the math by hand.
For later projects we had discussions about boundary checking. This was especially important around the time we talked about arrays. One always wants test data on either side of the boundary condition as well as on the boundary itself. This is the same time students usually discover division by zero and subscript out of range errors.
One problem with providing test data is that the occasional student will write special casing code to get around bugs that they are too lazy to fix so that the program works with the test data. That sort of code is open to all sorts of other errors and often will not work correctly with other data. For that reason I always made it clear that I would use a different set of test data for grading projects. This seemed to avoid most of the special casing but it had the more important value of causing many students to develop their own test data for their programs. And that is a good thing.
I found a couple of gems today. Dave Jacobus links to a tutorial that he plans to use with his Advanced Web Page Design class. The tutorial is here. Dave's blog entry about it is here.
And speaking about ASP .NET in the classroom - Brian Scarbeau has been blogging about teaching with ASP .NET in his classes. Day 1 is here but he's up to day 6 so read the whole blog.
More ASP .NET and other resources for computer science teachers as I find them.
PS: Dan Forhan has an interesting discussion on modifiers that teachers teaching Advanced Placement Computer Science may find usful.